@Zmaster said in Android rant:
@Martin_Tilsted said in Android rant:
@Zmaster said in Android rant:
All I'm asking is be able to use native (Java/C++/C#) objects in the app, without doing extra work just to pass the data between airtight Activities.
I understand it's not possible to just pass object references around because then you're still screwen when you need to preserve the Activity state in case of configuration changes. But this is indeed my point: why such a design? I can only see downsides and no benefits.But why? Either you need your Activities to be air airtight and then serialization is by definition the only solution because you are not air tight if you just allow passing objects in as is. (Otherwise you would allow any other app on the phone, to inject arbitrary objects into your app. You don't want that).
If you don't need your Activities to be air tight, then you don't really need to use multiple Activities at all.
An Activity is part of the program which can be used independently, and it is used to support loading of only part of the app(For performance) and sharing of parts of the app. (So other apps can call your Activity). It really sounds like you just need your app to be one big Activity.
I actually agree with you on the single Activity. Should I start from scratch, it looks like a better option.
This doesn't change the fact that Android will re-create the Activity in case of configuration changes though, so you still need to serialize all of your state.
You have to do this anyway, due to the nature of mobile apps. Because the user newer explicit starts or terminates apps, you have to handle the fact, that when your app goes to the background, the user may be back in 20 seconds, or he may be back after 3 months.
Btw: You can configure your Activity, not to be recreated when the user turn the screen around.