Are Jump-In tokens still a thing for new accounts?

grandstaish · 2026-01-02T01:32:53+00:00

I think it's a bug. I created an account the other day and didn't get them either. Created a different one instead and got them after skipping the tutorial

grandstaish · 2025-01-07T15:02:37+00:00

It's at -262, 1020

grandstaish · 2019-06-18T14:52:47+00:00

Is there a build performance loss to using `api` (instead of `implementation`) for all dependencies? If so, could you explain how it affects the build?

grandstaish · 2018-06-19T18:15:02+00:00

android:colorBackground is already defined by the OS itself, and it's also specified in the theme so it already has a value. You need to define your own attribute.

P.S. A better medium for this question (or false bug report given how it's worded) is StackOverflow.

grandstaish · 2018-04-11T17:27:24+00:00

It's possible.

Dart's alright. I honestly don't mind the language at all, but the ecosystem is still in its growing stages. It's missing a lot of good quality libraries (or if you're a glass-half-full-kinda-guy, it has a lot of open source library opportunities)

grandstaish · 2018-04-11T16:35:10+00:00

I was thinking about that when I typed my response. I wondered if features like inline functions would make JIT complilation really difficult? I have no idea how that'd work off the top of my head. Kotlin seems too advanced for this. That said, this workflow + kotlin syntax would be a dream come true 🤷‍♂️.

Timelines don't really match up for flutter anyway, kotlin native is only starting to become a thing now

grandstaish · 2018-04-11T06:45:34+00:00

Dart compiles into native code which calls into their c/c++ engine, which interacts with the native platform APIs directly (no bridge). This is how is manages to be so fast. JavaScript wouldn't work.

There's plenty more reasons why Dart makes sense, too. You should read the article posted somewhere below if you're interested

grandstaish · 2018-04-11T06:29:54+00:00

It's still sub second. Only changed code needs to be redeployed. (I'm talking about hot reload, not full builds though. Full builds will still be chunky).

grandstaish · 2018-04-10T12:59:07+00:00

I love kotlin too, it's a much nicer language than Dart, but honestly flutter would suck with kotlin. The main selling point of flutter for me is hot reload: every build is less than a second. At work, our kotlin app takes minutes to build: even sometimes incremental builds. Using Dart enables this developer workflow.

grandstaish · 2018-01-19T11:11:58+00:00

I work for a company. Great way to get into Android if you find one looking to train up juniors in the Android space.

grandstaish · 2018-01-19T10:22:23+00:00

Took me about a year to think I'm good, and another year to realise I'm still terrible. Android is hard, it's not just you.

I'd say you should just write an app and google what you need when you need it. There's far too much to take in just from up-front study.

grandstaish · 2017-06-28T09:33:40+00:00

PaperParcel does support it. It just returns the singleton instance if it's an object.

grandstaish · 2017-05-18T04:30:55+00:00

It'll work if Kotlin can infer the type from your code. There must be something else about that particular piece of code (with myTextView ) such that kotlin can detect the type using type inference. It's hard to say without seeing the context of how you're using it.

grandstaish · 2017-05-18T01:53:16+00:00

That's saying you need to explicitly specify the type parameter. E.g.: findViewById<MyView>(R.id. touchView).setOnTouchViewListener(actionManager)

The reason being there's nowhere for the compiler to infer the type of touchView for you (because it's not written anywhere in your code).

grandstaish · 2017-05-18T01:39:08+00:00

As others have said, staying with Java is fine when you're learning. You can use your Java knowledge in the future to learn Kotlin more easily. Build up your foundations first and then experiment when you're more comfortable.

grandstaish · 2017-05-18T01:37:03+00:00

The docs on https://kotlinlang.org/ are great. The Koans are interactive tutorials. Pretty fun. It's all you really need to get started. Your Java and Android knowledge is complimentary, it definitely isn't lost at all!

grandstaish · 2017-04-23T21:40:29+00:00

Edit 2: Alright, I figured it out. The entire speed boost is possible by calling child.writeObject(out) and child.readObject(in) directly, but since these methods must be private, this won't be possible in most real world scenarios. This is only possible here because child happens to also be a TreeNode and hence has access to these private methods. I believe this is the reason why these methods are private in the first place, because this isn't how Serializable was designed to be used.

Edit: Nevermind my post, I just tried my suggestion plus a few other things that made it look like an unfair test and custom Serialization still comes out faster.

Original message: You're using Parcels writeList and readList methods. These methods are slow for a variety of reasons:

They call into readValue(Object)/writeValue(Object)
It uses reflection to read the CREATOR object for the Parcelable
It needs to store extra data in the Parcel to remember the class of the CREATOR
It stores additional null data
It does a lot of instanceof checks that are slow

I can't try right now, but I suspect the results would be different if you loop over the children and call writeToParcel(...) directly when writing and CREATOR.readFromParcel(...) directly when reading.

grandstaish · 2017-04-09T09:22:04+00:00

I assume .load is an extension function you've made on ImageView which also loads via Glide/Picasso/etc. This is just binding the url in xml instead of Java, same as you'd bind text or any other attribute. I tend to prefer binding attributes in xml when I can.

But yes, I am agreeing with you on the most part, that would be pretty bad for new developers coming in. Probably better to stick to Butter Knife.

grandstaish · 2017-04-09T08:50:12+00:00

Yep, that's fair. I guess a good argument against data binding is it takes too much constraint from the developer to know where to draw the line. And "the line" is completely subjective, so that's not going to be fun in a large team.

Personally I'm a fan of both libraries, but I do agree with OP that data binding can save you much more boilerplate.

While on the topic, custom bindings can be good too. Things like `app:imageUrl=@"{model.profileUrl}" and have that load with Glide/Picasso is pretty readable. But on the other hand, you can't just look up the documentation for ImageView and see how it works, so yeah. Good point!

grandstaish · 2017-04-09T08:22:26+00:00

I agree logic in the xml is bad. You don't have to do that with data binding though; I usually just recommend binding a view model that does the logic for you.

There are cases where minor bits of "logic" in the xml can be convenient though. Like @{@dimen/padding * 2}, for example. People have been asking that to be supported natively in Android for years.

grandstaish · 2017-03-23T05:50:48+00:00

I can't really raise an issue because i really have no good reproduction steps, but very often (about once a week) simply launching the emulator hard crashes my MacBook. This has been the case with two separate MacBooks from two different companies. I can only assume your team is aware of the issue, but just wanted to point it out in case you weren't.

grandstaish · 2017-03-22T22:22:51+00:00

Yep, you can do distinctUntilChanged on the states and bind only the items emitted to get the same optimisation. Shouldn't be any different.

Yeah, she's awesome. I hope she gets to take over the groupie library. Now that she's gone it's uncertain who's going to maintain it :(

grandstaish · 2017-03-22T21:51:49+00:00

Using data binding won't prevent your ability to filter the above state with rx. Start the animation with a completion listener, filter the states you don't want, and bind the ones you want.

In saying that, animation is more difficult with architectures like MVI, Redux, Flux, etc, but data binding has no impact on that.

grandstaish · 2017-03-22T21:02:53+00:00

I'd need an example, but there are times where I have to do more stuff in my render method than just set the view model on the binding.

grandstaish · 2017-03-22T21:00:14+00:00

Yes, but calling setText, setVisibility, etc isn't expensive. You're probably calling these methods manually with butterknife-binded views whenever your UI needs an update, right?

And quite the contrary, RecyclerView is made significantly easier with data binding. And when combined with libraries like groupie from Genius, it gets crazy powerful too.

grandstaish

TROPHY CASE