5 ms·

This is just from my limited experience trying to develop mobile software around 2002 (J2ME and investigating Symbian) and developing for Android and iOS nowada

by babesh 14y ago

This is just from my limited experience trying to develop mobile software around 2002 (J2ME and investigating Symbian) and developing for Android and iOS nowadays. I developed 3 apps on J2ME at that time and investigated Symbian. The impression I got of Symbian of that time was that it was painful to develop against. J2ME was less painful but very, very limited. Think no animation support, just bitmaps, and I have to write my own game run loop, collision detection, etc.... This was most probably due to the limited hardware of the time but nonetheless, it was primitive. In comparison, iOS and to a lesser extent Android are basically fully featured OSs with mostly full exposed functionality. iOS gives you core graphics, opengl es, core text, core animation, grand central dispatch, networking, etc... Android gives you views, animation, background tasks, activities, intents, etc... The distribution model was also broken. If you wanted something distributed, you had to basically go with a carrier. There were attempts at an app store but there were not successful. Contrast this with the App Store, Google Play, and iOS enterprise development program where you don't have to go begging to a carrier to get your app distributed. To summarize, Symbian was coming from a previous era and had no chance. If you compare RIM's situation to Nokia's, I bet you will see a similar chart.

algolicious 14y ago
Could you explain what you mean by "to a lesser extent Android"? Android lets apps add widgets to the home screen, replace the home screen, replace the browser, run arbitrary background tasks, and so forth. You can even sideload apps and create your own app store. None of this is possible on iOS.
- cycle 14y ago
  iOS presents a programming model of MVC where the view can be anything. This is basically the same programming model as on OS X and similar to the programming model for windows if you use MFC. I found iOS libraries to be more traditional OS like and more mature. In contrast, Android forces you into activities, layouts, and intents. Layouts basically don't let you layout out things on a pixel basis unless you use the deprecated absolute layout. So Android is forcing you to try to write apps that work on a wide variety of devices and that interoperable with each other and they do this by forcing a different programming model on the programmer. How one transitions from one screen to another in iOS is how you would expect it to bd done in OS X or Windows. Android forces it via intents instead. Basically on iOS, I feel more in control except when the documentation is intentionally obscure but on Android I feel like I am programming in service of multi-device support, interoperability, and have to seriously limit the APIs I can use because over half of the devices out there are 2 major versions behind: no hardware acceleration and an animation system that has been replaced.
  - rbanffy 14y ago
    > Layouts basically don't let you layout out things on a pixel basis It's a natural approach when you have devices with different screen resolutions and sizes. Pixel-based layout works well when all devices have the same screen size, but break horribly when they don't. BTW, I'm curious on how the iPhone 5 runs iOS 4 apps.
    - cycle 14y ago
      Layouts also do not let you place views over each other. So there is also an assumption of a flat, non stacking space.
deathchill 14y ago
I am just curious but what changed after the iPhone? It seems like there were a couple of app stores (e.g. GetJar) before the iPhone, but I don't know if they differed before the iPhone or if they were basically a less popular earlier version. Did carriers have to approve apps that went into the store or did they have to approve the store as a whole?
- cycle 14y ago
  The app stores were not built into the phones. You had to navigate to those third party app stores via the web and download them to your phone. But that web navigation was done via your computer rather than your phone itself. The phones were serving a baby form of HTML that had to be routed via through the carrier if memory serves.
  - rbanffy 14y ago
    Many carriers intercept web traffic and, sometimes, inject headers.
- deleted 14y ago
  [deleted]

by babesh 14y ago

algolicious 14y ago

Could you explain what you mean by "to a lesser extent Android"? Android lets apps add widgets to the home screen, replace the home screen, replace the browser, run arbitrary background tasks, and so forth. You can even sideload apps and create your own app store. None of this is possible on iOS.

cycle 14y ago
iOS presents a programming model of MVC where the view can be anything. This is basically the same programming model as on OS X and similar to the programming model for windows if you use MFC. I found iOS libraries to be more traditional OS like and more mature. In contrast, Android forces you into activities, layouts, and intents. Layouts basically don't let you layout out things on a pixel basis unless you use the deprecated absolute layout. So Android is forcing you to try to write apps that work on a wide variety of devices and that interoperable with each other and they do this by forcing a different programming model on the programmer. How one transitions from one screen to another in iOS is how you would expect it to bd done in OS X or Windows. Android forces it via intents instead. Basically on iOS, I feel more in control except when the documentation is intentionally obscure but on Android I feel like I am programming in service of multi-device support, interoperability, and have to seriously limit the APIs I can use because over half of the devices out there are 2 major versions behind: no hardware acceleration and an animation system that has been replaced.
- rbanffy 14y ago
  > Layouts basically don't let you layout out things on a pixel basis It's a natural approach when you have devices with different screen resolutions and sizes. Pixel-based layout works well when all devices have the same screen size, but break horribly when they don't. BTW, I'm curious on how the iPhone 5 runs iOS 4 apps.
  - cycle 14y ago
    Layouts also do not let you place views over each other. So there is also an assumption of a flat, non stacking space.

deathchill 14y ago

I am just curious but what changed after the iPhone? It seems like there were a couple of app stores (e.g. GetJar) before the iPhone, but I don't know if they differed before the iPhone or if they were basically a less popular earlier version. Did carriers have to approve apps that went into the store or did they have to approve the store as a whole?

cycle 14y ago
The app stores were not built into the phones. You had to navigate to those third party app stores via the web and download them to your phone. But that web navigation was done via your computer rather than your phone itself. The phones were serving a baby form of HTML that had to be routed via through the carrier if memory serves.
- rbanffy 14y ago
  Many carriers intercept web traffic and, sometimes, inject headers.
deleted 14y ago
[deleted]