In this post, I propose a pattern for allowing apps to transmit data through unstable network connections. I’ll be taking advantage of the modern architecture present on the iOS Platform, as well as the popular AFNetworking (or AlamoFire). To follow along, you’ll need some knowledge of iOS Native Development, NSOperation API, CoreData, and Networking.
“WHAT THE HECK?! HOW CAN I UNLOCK MY PHONE WITH MY FACE?!”
Those were the words that came out of my mouth in October of 2017, as I pored over the user manual for my new iPhone X. It wasn’t all hyperbole, either — I really wanted to know, and I ended up dedicating quite a bit of time to learning about the science behind Apple’s new facial recognition technology. In the end, the answer to my question boiled down to two words — machine learning.
A mobile app is a great way to bring new ideas to life, add value for your customers, or boost awareness of your business—but only if you can build a quality mobile experience without breaking the bank. And nailing down the cost of an app in advance isn’t exactly easy. App development costs can range from trivial to extreme, depending on a host of factors such as what your app does, how users will interact with it, and how you plan to staff the project.
These days grocery stores are facing many challenges, like high maintenance costs, price competition with online stores, and limited business hours. All of these issues can be solved with unmanned grocery stores.
If you are building a mobile application of any sophistication, you are likely to need some services to support your app. You’ll need a way to distribute your app for testing prior to submitting to the app store(s), as well as analytics, error logging, crash reporting, and possibly user and data management services. Of course, you could write these services yourself and provision servers to host these services, but why do that when you don’t have to?
Your company needs a mobile app and you want to save money (of course). You want the app live last week, and you’d really like to avoid hiring Android and iOS devs on top of your existing web team.
What’s your favorite chocolate chip cookie recipe? I bet you could ask that question to 5 different people and get 5 totally different recipes… brown sugar vs white sugar, cake flour vs all purpose, dark chocolate vs milk chocolate. All of these recipes result in a chocolate chip cookie but the process by which we get there is a matter of personal preference. If you were to ask multiple developers to solve a problem, it’s doubtful that any two developers write identical code. It’s not that any one solution is necessarily better than the others… the resulting code is likely just a matter of personal preference.
Overstuffed View Controllers: a problem that is universally despised by iOS developers the world over. Who hasn’t had their eyes glaze over while staring down debugging a 3000 line VC? View Controllers can control so much information, and Apple seems to have very few opinions on where specific logic should go. They give us the decision making power. How can we prevent against this annoying problem and modularize our apps better? Model–View–View Model (MVVM) can certainly help with this, but ultimately leaves routing to View Controllers, which doesn’t make the most sense. This is where a Coordinator comes in.
There are a lot of APIs out there, a lot of networking layers, a lot of abstractions, I’m going to offer just one way to start building Swift models backed by a RESTful API. Out of personal preference, PromiseKit will be used instead of callbacks and ObjectMapper will be used to convert between JSON and Swift objects.
Pixel density is the number of pixels per linear physical unit. Measured in pixels per inch (ppi or dpi). Pixel density and resolution are technically the same thing, but often people say “resolution” to mean “pixel count,” a related metric:
count = densityH * width * densityV * height
When other things are held constant: