A junior developer starts to develop everything by himself. However, a little experience or help will teach him that it’s not useful to write every little piece of code on his own.
Enthusiastic developers provide a lot of good and widely tested solutions for problems almost everyone faces during development. Using these libraries can save you a lot of time.
There are a couple of libraries a developer almost always uses in his apps, it’s not a secret, code reusing is a good thing. Here they are:
Retrofit is a widely used Android lib for http communication, it is annotation based (for methods, headers, encoding and even url manipulation per call), it supports RXAndroid, therefore it can provide you with Observables instead of Callbacks. All your API calls are organized in a readable interface class, and you have to build a retrofit service for common API handling functions (such as converters).
Alamofire is the iOS equivalent of Retrofit. You can write requests in one line, but you can customize your calls with Alamofire.Manager. Alamofire has several built in response serializers, and an encoder too. The calls are automatically cached. Alamofire handles file downloading and uploading too, even showing the state progress. It has different validation, and authentication methods, and you can track the lifecycle of a request with the timeline function.
Android GSON is an easy to use library for JSON serialization and deserialization issues. You only have to provide the type of the object you want to get, or TypeToken for collections, or generic types. You can also annotate the fields of your object to be different than what you’ve used in the response. GSON can be forced to support null objects, objects can be versioned, and specific fields can be excluded as well.
iOS has two good options for different purposes. If you need a quickly usable library to parse a relatively little amount of data with low complexity, there is SwiftyJson for you. With SwiftyJson, you can easily map your object fields with json keys, and accessing to array elements has never been easier either. SwiftyJson also has built in error handling, especially for arrays (for example array out of bounds exceptions). On the other hand, with a huge amount of complex data OCMapper can be a better choice. OCMapper can automatically map your objects fields, therefore you need only one line and no bolierplate to parse the JSON. However, if you need to modify the mapping, you can provide Mapping Providers to accomplish this. There is an entire post on JSON handling.
Downloading images is an average task in almost every mobile app. There is no problem if you want to download only one picture and show it only once.
But in mobile apps, if images are in lists or even in grids, you have to load a couple of images at the same time, and load more on swipe. You also have to reload the same images if the user swipes back again.
Your app has to be responsive during this heavy work; it cannot lag.
With third party libraries this bunch of work can be done in a few lines.
With Picasso, you can provide a placeholder and an error image, too. Or you can set a listener in progress, and even resize the images. It also caches the images in the background.
Glide is almost the same as Picasso, but has a built in revealing animation, and supports GIFs too.
HanekeSwift has similar capabilities for iOS apps. Its main purpose is caching, but it is perfectly fit for images, too. It provides easy to use methods, but you can customize the workflow with callbacks too.
EventBus decouples senders and receivers. Someone can post an event, and if another class subscribes to this specific type of event, then this class will get the newly sent events, otherwise it will not. You can create specific eventtypes, and subscribe on different threads only with an annotation.
Otto works almost the same way, but you need a few more lines for thread handling than you did with EventBus. Otherwise, Otto can provide an initial event or data for subscribers by Producer annotated methods. If there is a new subscription for the same type of event (that any registered producer could have created) then this class will get the last event, or anything you have provided.
There is also a solution for iOS developers, called SwiftEventBus. It also handles different threads, and the events are filtered by their name not their type (you have to cast the message parameters).
Logging is important during the development phase, therefore there are built in solutions for both platforms, but those are basic ones.
For Android there are three good libraries for extending your logs.
Timber automatically tags your logs. Hugo is an annotation based logger, you can annotate your methods, and Hugo will log its in-out parameters. And finally there is Frodo, with RxAndroid support. Fordo can log the magic that happens during working with RxAndroid.
Reactive programming is a technology spreading fast for asyncronous programming with observable streams. Both programming languages try to port most concepts of the original version, therefore they use quite similar methods and work almost the same way.
Android has RxAndroid, and iOS has RxSwift for earning the advantages of RX. You can work with different async operations, combine and manipulate them, there is also an eventbus-like feature in RX too. With RX you can easily change between main- and background thread, handling the logic and heavy work on the right thread, keeping the UI responsive.
Working with dates can be difficult sometimes, and the built in versions are not enough help.
YodaTime provides a lot of easy and useful methods in a builder-like way, for comparing, modifying or forming dates.
For iOS SwiftMoment is perhaps the easiest tool. It has most of the functions we usually use, for example it implements the compare-operators, so we can create a sort method from it. The disadvantage is that it creates a new class and it is not an NSDate extension, so you cannot use it with other libraries. If we want to use time periods, we should use DateTools, because it has a built-in class that handles the time period operations. It also has the timeAgoSince methods, which can easily show the elapsed time. If it necessary to use the NSDate class, then we should use the devxoul/Date.swift library, it has the most common methods and extensions we need to handle dates.
If you have at least one input view, validating input views is an important task.
Android gives you the annotation based Android Saripaar v2. You can annotate your widgets with rules, conditions and error texts, and you can also determine the order of the validation.
iOS has its SwiftValidator for validation, it has predefined validating rules (you can write your own too), and callbacks, and you can register with or without error labels, and custom error messages too.
If you are tired of writing findViewById all the time, ButterKnife is really useful, it has a generator for binding. It can handle UIActions, and resource binging too, without boilerplate codes.
Using custom fonts has never been easier, you need to inject Calligraphy into the context, then you can set the custom font in the xml layout files.
Separating application layers is important for creating robust and reusable code. There are a few design patterns to help you deal with layer separation. One of the best Android MVP pattern is Mosby, it provides templates for activities and fragments too. There is a simple skeleton for fragments or activities. There’s another one with prebuilt functionality for loading views, too. Plus, Mosby also shows a way to keep view states during (for example) orientation changes with retainfragments.
Of course, there are tons of other libraries we can use. This is a handful and tested a bunch of them; these will help you face some of the most common problems you might encounter during development.
Personally, I think RxAndroid with Retrofit is a must, all the others are just cherries on top.
*You should also watch out for new versions.
[Editor’s note: to learn more about the author, visit our Facebook page.]