Starting at a new company can be pretty stressful, especially when you never worked at one before. Beeing entrusted to build up a new product and develop an Android and an iOS app however, is a completly different situation, when its your first company app ever. We began to work as interns, but we kinda felt us as normal employees. Never the less, we had a lot of support by our co-workers, and settled in quickly.
Familee, the project we were entrustet with, was set up to use a lot of the code of an already existing product and parts of the corresponding backend, the relution emm suite. So we had to spend a significant amount of time reading that code and the documentary of the REST interface. After that, we began getting to know the IDEs and a lot of the OS components, we never worked with before. That included watching a hell lot of tutorials, reading even more How To and playing around with the IDE’s until we got the hang of it. We had the advantage of beeing in the same office and working together on every Feature simultaneously, which gave us the opportunity of finding the best solutions for both Android and iOS. While working together, we quickly realized how much iOS and Android differentiate from each other.
Autolayout in general is a very nice feature for building views. You only have to build one view which will be adjusted for every screensize automatically. While that sounds awesome the reality looks otherwise. There’s always something that comes out too big or too small for me when testing on different screensizes. So i had to come up with another solution. There is a german quote which translates to “What doesn’t fit is made to fit”. So in other words, I customize every view that doesn’t fit my expectations afterwards in my Code. To achieve this I connect the constraints that have to be changed as outlets to my code and change the constant property accordingly to every screensize. Another thing that bugs me really hard is scrollviews. I don’t know why but apple made building scrollviews with autolayout so confusing that I could smash my monitor sooner or later every time I attempt building one. Until this day I wasn’t able to build a scrollview that didn’t throw any warning, but somehow they work. So let me share how i build scrollviews.
- If you know your view is going to be way longer than your given view in Interface Builder, click on your view and set the size to ‘freeform’. This gives you the option to change the width and height of your superview. Don’t worry, the view will shrink back at runtime. It just helps you seeing all your content.
- Drag a ScrollView into your View and connect all sides to your superview with zero distance.
- Drag another View (your contentview) into your view. Now here comes the tricky part. If you don’t know how big your content is going to be, lets say you have a tableview which can have a length of 200 points or 2000 points, connect every side with zero distance except the bottom, give it a fixed height and center the contentview horizontally, if you want to have a vertical scrollview or connect only top and bottom, give it a fixed width and center vertically, if you want to have a horizontal scrollview. This will give you a warning saying that “scrollview has ambigous…” but you can ignore it.
- Place your subviews into your contentview and only your contentview.
- Connect your subviews as outlets to your code, don’t forget the fixed width/height.
- In your code set the height/width constraint to your desired size and also the contentSize property of your scrollview and voilá, your scrollview should work.
Of course there are other ways of building scrollviews, but that’s the best I came up so far and it works for me.
NSUserDefaults, Core Data or write to file
There will come a time where you want to save something in your app and if that time comes you should know what method you should use. If you want to store simple objects and very small things you should use NSUserDefaults, because it is very easy to use. If it has to be some pictures NSUserDefaults isn’t the right solution because it reads very slow and you would get performance issues. That is the time to create files in which you can store your images. You should only use Core Data if you have really complex objects or if you have a massive amount of things to store. The benefit of Core Data is that it’s way faster than the other two possibilities but also much more complex.
Block Code vs Delegates vs Notifications
At the start of our first project, familee (which actually was the first productiv app I developed), I wasn’t quite sure how to notify other views or managers about changes. Should I use block code? Or delegates? Or Notifications? Or all of them together? I wasn’t sure and google was neither. The only thing left was to try all of them and choose for myself. And that’s what I came up with: Delegates are a cool thing, if you know will get notified, but don’t know when exactly. For example location updates. Notifcations are very easy to code, but you can’t be sure your view/manager/whatever will actually get your message. It’s a good thing if you want to notify other views to change their layout if something in another view happend, but it has to be timed correctly or else your notification won’t reach anything. Block codes are awesome when you want to notify your user if a function/call worked or not or start another function when the previous succeeded. They first look quite complicated but they’re actually very easy if you get the hang of it. I mainly use block codes and sometimes notifications in familee and never had the feeling of building my own delegates because block code did the job better for me.
Different Layout Types
Android relies mainly on xml files with different layouts to implement the views. It offers you a few predifined layouts like Linear Layout, Frame Layout or Relative Layout. With those three, youre able to build any view you want. Try to use Linear Layout or Frame Layout as often as you can though, because they are faster than the Relative layout. While a Frame layout gets rendered twice, the Linear Layout gets rendered 4 times and the Relative Layout even 6 times. However, of you put a linear layout in a linear layout or nested weights, it gets rendered 16 times or even more. So you have to preconsider the layout that is best for displaying all the content in the right place of the screen and to archive the best possible performance.
Databank vs Shared Preferences
Whenever you get to the point to save data permanently on the device, you have the choice between two features provided by android. When i started to develop android applications, i was always uncertain which one i should use. Finally i came to the conclusion that its important what kind of data you want to save and how often you want to access and change it. Shared preferences are a fast solution to store and retrieve simple datatypes and strings. Whenever it comes to storing objects, you can still use shared preferences, but you have to serialize the data first. A good library for that would be googles gson. However, if you want to access the object again, it has to be deserialized. Both serializing and deserializing takes time and performance. So if you wanna access, change and save the object again, storing it in the shared preferences is not the best solution. You should consider using a databank in this case, because its faster and offers you different methodes, like selecting or deleting a specific object. You also have the opportunity to store a lot of objects, while the shared preferences are based on a key – value pair.
Before I started to work at M-Way, I had totally no idea how to develop an app efficiently. I used to copy/paste my code in every activity or in every xml file, as long as it seemed to work. Here are some examples to do it better:
- Whenever you have activity that provide similar logic or content, try to move as much as you can in a super class activity and execute it there. The easiest way to do so is to implement an abstract super class which also extends from activity, that forces the sub classes to pass data to the super class by implementing abstract methods. I know, that’s basically how you develop java in general, but it was kinda new for me in the android context.
- As it is with java code, reuse xml code as much as possible. Best practice is to put that piece of xml code in its own xml file and include it in every view. Even further, if that xml corresponds to its own java code logic, put that code in a new file as well and extend from View or any other View component that fits better. Now you can just use that view by creating an instance of it in your activity. That will keep your code in the activity a lot cleaner.
- Use all the xml resources provided by Android. Instead of hardcoding dimensions, colors or sizes, set a specific style for e.g. a button in the styles.xml and include that style in every button to make them look the same.
Those tips will help you write better code and improve your app overall. We used all these things in our project called familee. Check those apps out and decide for yourself.
Authors: iOS (Marco Milovanovic) and Android (Pascal Weik)