Hacker News new | ask | show | jobs
by shawkinaw 3326 days ago
Two thoughts. First, I also thought Android programming was horrible at first, but have since come to see it as no worse on average than iOS programming. The only really sucky thing about it IMO is the lack of ability to pass an object to another activity without serializing it (or maybe there is one I don't know about.) But since everything is done with fragments now that's moot anyway.

Second, I tried Kotlin and liked it a lot, but found it so much like Swift that my brain kept thinking it was Swift, so I ended up making mistakes and getting frustrated. That would probably go away with experience though.

4 comments

It's hard to pass objects like that because it's a terrible idea. If you can't serialize the object then your state isn't stored and you'll possibly lose that object on a screen rotation and activity restart.
It's a pretty terrible design to couple activity state to the physical orientation of the device.
No, you don't understand. The state is serialized and stored. You might navigate away or pop into a windowed state. These things might rebuild your activity and the idea is your state should be serializable. The idea is every activity can be restarted outside of your control and your state should be fully storable.
No, I understand the Android Activity lifecycle quite well. I think it has severe flaws from a design perspective.
Not from design, no. Design is pretty sound.

It has implementation issues - you get to use a crusty ContentProvider or manually serialize everything into also crusty Bundle. Then you have that separate SharedPreferences thing. Or you can do it on your own, typically more cleanly, with an object database.

Instead it would be often fine if it just took a Java Serializable and ran with it, just call you back so that you can read all the state and redo whatever you need to redo.

Likewise IPC with Intents is pretty crusty as is with Binder, though bit less with the latter.

To be fair, there may have been really good reasons for it back when Android devices had 500 Mhz single-core CPUs with 32 or 64 Megabytes of RAM.
Still good reasons when a web browser eats 500 MB.
You can always handle the orientation change manually if you want to. But if you don't want to bother, restarting the Activity seems like a reasonable default.
How would you do it?
The passing of things from activity to activity does feel vaguely boilerplatey, on the other hand I have to review my colleagues' IOS code from time to time and there's always an issue with a view loading data, then loading a view on top of that with another different set of data, and so on, until the app runs out of memory that I'll have to fix by making it work like the Android app by serializing all the data when the views disappear.

We could fault the design for stacking all those views but that's another issue.

> I also thought Android programming was horrible at first, but have since come to see it as no worse on average than iOS programming

Those two statements are in no way mutually exclusive.

(That said, Swift is infinitely better than writing Android Java code, in my limited experience)

Heh, that's true. I should have also mentioned that I generally enjoy iOS programming :)
They did recently provide better APIs to address most of the Activity/Fragment issues https://developer.android.com/topic/libraries/architecture/i...

There was a talk about it on this IO https://www.youtube.com/watch?v=FrteWKKVyzI.