After an engineer with 5 years of iOS development desperately worked hard and assigned to Android development for about half a year I wanted to give my impressions.
As a point that iOS engineers stumbled upon when embarking on Android development
--UI design design and how to handle UIKit --Handling of Optional --Resource file --Differences between Activity and Fragment and proper use --Handling of layout files
If this point is suppressed, I think we can overcome the first three months even on a large scale (optimistic). The Resource file also contains Color changes from the source code.
I think it will be a little easier if you overcome the above 5 points, The next big wall, or the small difference, is
--How to design UI design --Language specifications --Add and import libraries --Handling of Optional --IDE features --About variable declaration --About Resource file --Handling of UIKit --App life cycle --View life cycle --Handling of arrays and types (List, Array, ArrayList, Nanjarahoi)
I thought it was about this. After getting used to these, I can now develop Android with confidence as an iOS engineer.
Let's look at each one.
iOS | Android |
---|---|
UILabel | TextView |
UIButton | Button / ImageButton / etc |
UIImageView | ImageView |
UIView | View |
UITextView | TextView |
UISwitch | Switch |
UIWebView | WebView |
UITableView | ListView |
UICollectionView | RecyclerView |
UIScrollView(Vertical scroll) | ScrollView |
UIScrollView(Side-scrolling) | ViewPager |
Is it something like this? Isn't it good to hold down these points?
However, for iOS design, consider the design pattern generated from the code and the composition with Storyboard and xib, etc. There are several patterns. On the other hand, in the case of Android, I can only think of a pattern for editing an XML file.
So you shouldn't have to worry about design patterns. On the other hand, if an Android engineer touches iOS, there is a big hurdle called Autolayout. Therefore, I think that iOS-> Android has little development resistance, but Android-> iOS I'm guessing it's pretty tough.
Also, since Android is Kotlin / Java, it was a big merit that there was no cost to be aware of pointers. When pointers are involved in application development, the frustration rate increases (experience story).
I learned the language in the order of Ojbc → Swift → Java → Kotlin, After all, handling Java Optional was very difficult.
If you write Java after getting used to Swift's Optional, it will become "Optional Mendokusei" in one shot. That's how amazing Swift's Optional is.
Once you get used to writing Optional, it's normal.
Resource management for iOS is different for each application, but Android has a guideline of "do this" It was decided, so I didn't have to worry too much. However, there are several ways to refer to Color and Image files from Resources, so There was a demerit that I forgot how to write depending on the design. It's already hard.
Android development, brightness adjustment from RGB color to HSV
However, the disadvantage of Android is when implementing rounded corners, drop shadows, borders, and gradients. It is very difficult to manage the XML file because it is necessary to create and set the XML file one by one. On the contrary, iOS was quite excellent.
If possible, I want you to be able to implement it quickly with a few lines of code like iOS. I often regret receiving requests for borders, rounded corners, and drop shadows on iOS. If you are creating an XML file, wouldn't the file take up space?
Not to mention the animation, iOS is better, and I get the impression that Android doesn't want to get involved too much.
In order to implement MotionLayout
in recent Android, it is necessary to prepare an XML file.
I want you to be able to implement such a thing with just code.
MotionLayout (Android Developer)
I've been involved in Android development little by little since Android Studio 1.0, so
I understood the concept of ʻActivity, but it was difficult to understand
Fragment`.
(Initially, other Android engineers seemed to have the same opinion)
However, this is easy to understand, and if you want to tell an iOS engineer
It's like a UIView Xib
file.
(Activity is a class corresponding to ʻUIViewController`)
Once you know that, the later design policy is almost the same.
It seems to be taught that View has a life cycle added
,
It is the same as that after connecting Xib
and ʻUIView`.
It was hard to get there.
For example,
Android Layout File = iOS AutoLayout
It's similar to. I thought it would be easy to convey if I said this.
For Android, the design policy changes depending on which Layout is used for placing parts.
However, if you use Layout incorrectly, the XML file will be messed up (experience story).
If you think of it as LinearLayout (Vertical
), the iOS engineer interprets it as" Ah, the vertical constraint of the part. "
That leads to misunderstanding.
The way of thinking was quite different from iOS, so Placing layouts in XML was a daunting task.
Beyond this, Android is easier to design because AutoLayout is not required. It also does a good margin after rotation.
I tried to summarize the impressions of developing Android for about half a year like this. Beyond this part, I think iOS engineers will be able to cover Android. (Ah, there was another contrast between closure and lambda expression.)
I'd like to do Android development as an iOS engineer, but I'm scared. If you are thinking, you should be able to see the wall to overcome in this article. If you focus on this, you will be able to use Android relatively quickly.
Recommended Posts