New to the transition from iOS to Android
Translation of this post in google .
I bought myself a Nexus S. I programmed for Android for the last few days. The Android API requires users to be very good programmers. Android abstractions are much more sophisticated (bloated, imposed, overcomplicated) than their iOS equivalents. Meanwhile, the “intents” are wonderful, but only if you enter them .
Sorry, all that comes next is a stream of consciousness. tl; dr
')
After a couple of days of iOS programming, I had a working application. After a couple of days of Android, I just started to understand abstractions.
It seems that Android developers wanted to give the consumer API (application developers) the freedom to do whatever you want. Meanwhile, the depth of knowledge of design patterns is required so strongly and so meaningless that most application developers will study only 50% of the things needed to complete the task, and finish foot sweeping, suddenly destroying usability in the remaining 50%. iOS allows you to put a gun on his leg, but also gives the opportunity to never pull the trigger.
For example, to correctly implement asynchronous HTTP, on iOS and Android you need to go through completely different tests. On iOS, you can use the built-in libraries, and if the user suddenly switches between applications at the time of the request, you can be sure that you have up to 30 seconds, usually more, to finish your tasks before the application completes. On the android, you need to implement the android app service, api for all important network calls. The application can be killed at any time, so you must keep all your arguments, and try to make the call again in case it really dies.
This is called “good practice” and is said to be suitable for 99% of cases (albeit with a lot of unnecessary code and work on your part). Decisions in the field of design become obvious as soon as you understand that the limitations of the equipment and providers are an integral part of the android, meanwhile it gives little joy to application developers. iOS supports methods that are also suitable for 95% of cases, but at the same time require much less effort from the developer to create a properly working application.
IOS developers have access to excellent documentation. In places where the iOS / Cocoa / Core * documentation library is usually very good, leading the developer in the right direction, towards simpler abstractions, the Android documentation makes several assumptions, it assumes excellent knowledge of Java development patterns, and this is in addition to its own Android patterns. For example, here: “android.content.ContentProvider” or “android.app.Service”.
There is huge potential in the development for Android, and there are some really good applications. Only I feel that they are not in this area . More abstractions are needed so that we (mobile application developers) can quickly understand the issue, with 95% accuracy. At the moment, we have an API that allows us to make an ideal application, but only if we want to invest months in researching (anti?) Design patterns for Android so that our first REST request works correctly. And you can still be a specialist in Computer Science - but, in fact, not all of us went down this path. In fact, few of us (note almost all the great apps for iOS).
I bought myself a Nexus S. I programmed for Android for the last few days. The Android API requires users to be very good programmers. Android abstractions are much more sophisticated (bloated, imposed, overcomplicated) than their iOS equivalents. Meanwhile, the “intents” are wonderful, but only if you enter them .
Sorry, all that comes next is a stream of consciousness. tl; dr
')
After a couple of days of iOS programming, I had a working application. After a couple of days of Android, I just started to understand abstractions.
It seems that Android developers wanted to give the consumer API (application developers) the freedom to do whatever you want. Meanwhile, the depth of knowledge of design patterns is required so strongly and so meaningless that most application developers will study only 50% of the things needed to complete the task, and finish foot sweeping, suddenly destroying usability in the remaining 50%. iOS allows you to put a gun on his leg, but also gives the opportunity to never pull the trigger.
For example, to correctly implement asynchronous HTTP, on iOS and Android you need to go through completely different tests. On iOS, you can use the built-in libraries, and if the user suddenly switches between applications at the time of the request, you can be sure that you have up to 30 seconds, usually more, to finish your tasks before the application completes. On the android, you need to implement the android app service, api for all important network calls. The application can be killed at any time, so you must keep all your arguments, and try to make the call again in case it really dies.
This is called “good practice” and is said to be suitable for 99% of cases (albeit with a lot of unnecessary code and work on your part). Decisions in the field of design become obvious as soon as you understand that the limitations of the equipment and providers are an integral part of the android, meanwhile it gives little joy to application developers. iOS supports methods that are also suitable for 95% of cases, but at the same time require much less effort from the developer to create a properly working application.
IOS developers have access to excellent documentation. In places where the iOS / Cocoa / Core * documentation library is usually very good, leading the developer in the right direction, towards simpler abstractions, the Android documentation makes several assumptions, it assumes excellent knowledge of Java development patterns, and this is in addition to its own Android patterns. For example, here: “android.content.ContentProvider” or “android.app.Service”.
There is huge potential in the development for Android, and there are some really good applications. Only I feel that they are not in this area . More abstractions are needed so that we (mobile application developers) can quickly understand the issue, with 95% accuracy. At the moment, we have an API that allows us to make an ideal application, but only if we want to invest months in researching (anti?) Design patterns for Android so that our first REST request works correctly. And you can still be a specialist in Computer Science - but, in fact, not all of us went down this path. In fact, few of us (note almost all the great apps for iOS).
Source: https://habr.com/ru/post/125318/
All Articles