4 ms·

the problem with Android is the god awful API, not Java this says it all: https://cdn1.hubspot.net/hubfs/2564010/The%20activity%20and%20fragment%20lifecycles%2

the problem with Android is the god awful API, not Java this says it all: https://cdn1.hubspot.net/hubfs/2564010/The%20activity%20and%20fragment%20lifecycles%20(1).png https://cdn1.hubspot.net/hubfs/2564010/The%20activity%20and%... and it gets worse with every release

kumarm 7y ago
How is that Bad? Any Activity you have need to have proper lifecycle. Every UI Toolkit has something similar. Same events for IOS: https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle https://developer.apple.com/documentation/uikit/app_and_envi...
- blibble 7y ago
  no UI toolkit I've used has anything nearly as complicated or error prone it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS as a result you need to implement masses of error prone boilerplate crap for each and every activity, and nearly everyone gets it wrong in subtle ways rotate your screen? better implement that serialisation perfectly else the user will lose state when they rotate their device a lot of apps just disable features like rotation, because they're too time consuming to implement (and a nightmare to test)
  - ShamelessC 7y ago
    I've never understood why rotating the app resets the state like this without writing code to handle it. I mean even a lightweight website can change its interface on rotation using only CSS without losing any state. It's been several years since I messed with Android development. I assumed it would be fixed by now.
    - jabot 7y ago
      Maybe that's because the website already has a serialized state - the HTML?
    - izacus 7y ago
      Because the alternative is not resetting the state and having to deal with the fallout. iOS does this and it's a source of even more strange bugs and side issues (based on doing cross-platform development across several teams). This even led to the point where a huge amount of iOS apps simply banned rotation support to not deal with it. It's just a different tradeoff. The underlying issue is that developers don't want to deal with storing the state which causes issues on lower end devices, which start to break as users multitask. The Android tools for that also aren't all that great - although I also haven't really seen any other toolkit do it better.
      - cerberusss 7y ago
        I'm an iOS developer and I'm not sure what you mean. Auto Layout provides enough hooks to take care of rotation. Why would rotation be a source of strange bugs and side issues?
        izacus 7y ago
        Because not all the state and layout is handled by AutoLayout... and it has its own set of bugs. Heck, iOS apps themselves (iMessage, Springboard) and riddled with rotational layout bugs in iOS 12 and 13.
        cerberusss 7y ago
        But how bad is it, I mean how many have you encountered so far? I don't doubt it, but in my years of iOS development, I haven't seen them.
    - jinushaun 7y ago
      Because web has “unlimited” memory. Mobile devices don’t, especially if you have an OS that aggressively kills apps to maintain decent battery life. That said, I agree. Rotation should not be conflated with general app suspension. They are two different concerns. iOS does this.
  - izacus 7y ago
    > it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS This is literally how iOS and other mobile toolkits work as well.
  - pjmlp 7y ago
    Windows CE and Symbian weren't as complicated and yet had even less memory to play with.
Abishek_Muthian 7y ago
I agree and include the Toolchain mess as well. e.g. Look at this issue[1] of Fragments in the LinearLayout, every now and then with the update of the SDK; the order of fragments changes i.e. with one SDK version the fragments are displayed in the order it was added 1,2,3,4 and with an update to SDK the order is 4,1,2,3 or any other. For issues like this, every time I updated the SDK I had to spend lot of effort in testing and mitigating issues which were unwarranted. Meanwhile, my colleagues(whom I trained) who developed the same application for iOS didn't face such issues with API/Toolchain i.e. in iOS development what doesn't work, don't work and there is no hidden surprise with each SDK/Build Tools/NDK etc. updates because they are not updated separately. [1]https://issuetracker.google.com/issues/37086731 https://issuetracker.google.com/issues/37086731
jinushaun 7y ago
I don’t see the problem with that diagram. It’s a consequence of your activity/fragment potentially being killed at any time, something you need to be aware of on mobile devices. iOS has same diagram.

kumarm 7y ago

How is that Bad? Any Activity you have need to have proper lifecycle. Every UI Toolkit has something similar. Same events for IOS: https://developer.apple.com/documentation/uikit/app_and_environment/managing_your_app_s_life_cycle https://developer.apple.com/documentation/uikit/app_and_envi...

blibble 7y ago
no UI toolkit I've used has anything nearly as complicated or error prone it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS as a result you need to implement masses of error prone boilerplate crap for each and every activity, and nearly everyone gets it wrong in subtle ways rotate your screen? better implement that serialisation perfectly else the user will lose state when they rotate their device a lot of apps just disable features like rotation, because they're too time consuming to implement (and a nightmare to test)
- ShamelessC 7y ago
  I've never understood why rotating the app resets the state like this without writing code to handle it. I mean even a lightweight website can change its interface on rotation using only CSS without losing any state. It's been several years since I messed with Android development. I assumed it would be fixed by now.
  - jabot 7y ago
    Maybe that's because the website already has a serialized state - the HTML?
  - izacus 7y ago
    Because the alternative is not resetting the state and having to deal with the fallout. iOS does this and it's a source of even more strange bugs and side issues (based on doing cross-platform development across several teams). This even led to the point where a huge amount of iOS apps simply banned rotation support to not deal with it. It's just a different tradeoff. The underlying issue is that developers don't want to deal with storing the state which causes issues on lower end devices, which start to break as users multitask. The Android tools for that also aren't all that great - although I also haven't really seen any other toolkit do it better.
    - cerberusss 7y ago
      I'm an iOS developer and I'm not sure what you mean. Auto Layout provides enough hooks to take care of rotation. Why would rotation be a source of strange bugs and side issues?
      - izacus 7y ago
        Because not all the state and layout is handled by AutoLayout... and it has its own set of bugs. Heck, iOS apps themselves (iMessage, Springboard) and riddled with rotational layout bugs in iOS 12 and 13.
        cerberusss 7y ago
        But how bad is it, I mean how many have you encountered so far? I don't doubt it, but in my years of iOS development, I haven't seen them.
  - jinushaun 7y ago
    Because web has “unlimited” memory. Mobile devices don’t, especially if you have an OS that aggressively kills apps to maintain decent battery life. That said, I agree. Rotation should not be conflated with general app suspension. They are two different concerns. iOS does this.
- izacus 7y ago
  > it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS This is literally how iOS and other mobile toolkits work as well.
- pjmlp 7y ago
  Windows CE and Symbian weren't as complicated and yet had even less memory to play with.

Abishek_Muthian 7y ago

I agree and include the Toolchain mess as well. e.g. Look at this issue[1] of Fragments in the LinearLayout, every now and then with the update of the SDK; the order of fragments changes i.e. with one SDK version the fragments are displayed in the order it was added 1,2,3,4 and with an update to SDK the order is 4,1,2,3 or any other. For issues like this, every time I updated the SDK I had to spend lot of effort in testing and mitigating issues which were unwarranted. Meanwhile, my colleagues(whom I trained) who developed the same application for iOS didn't face such issues with API/Toolchain i.e. in iOS development what doesn't work, don't work and there is no hidden surprise with each SDK/Build Tools/NDK etc. updates because they are not updated separately. [1]https://issuetracker.google.com/issues/37086731 https://issuetracker.google.com/issues/37086731

jinushaun 7y ago

I don’t see the problem with that diagram. It’s a consequence of your activity/fragment potentially being killed at any time, something you need to be aware of on mobile devices. iOS has same diagram.