Special thank you to our iOS Engineers Anastasiia and Vitalii Bogdan for contribution to this article.

Since Facebook announced shutting down its mobile backend as a service (mBaaS) platform Parse, a huge number of developers have taken their frustration to all corners of the Internet. From a lengthy discussion of the reasons on Quora to a petition on Change.org signed by over 700 people, the community feels gutted and is starting to look for alternatives.

A platform that allowed to deploy backend for mobile apps without code, Parse was about perfect in terms of pricing, reliability, and feature set. Developers at Stanfy were avid Parse users as well, as Anastasiia put it almost a year ago:

We use Parse.com because it solves our problems. We tried it several years ago and built many applications using it. Some of them support features like anonymous login, geo-based push notifications, and offline synchronization. There were social apps (post-like-comment-share actions included) and personal apps (on-the-fly customization and offline mode).

Here’s a look at the alternative solutions available on the market now, from other mBaaS to full-fledged self-hosted backend.

Taking Matter In Your Own Hands

For the brave people among us, there’s the ultimate solution: create your own backend from scratch. Allocate cloud server instance or whole server rack, define hardware you want, use operating system that you prefer, deploy database that suits better, install modules that you like.

Then learn how to handle load balancing of your servers and version compatibility of your tools, and don’t forget to install security updates and add more RAM modules. What could possibly go wrong? ;)

Jokes aside, building your own backend solution is the most future-proof idea of all. You can be sure no one’s going to pull the plug on your service of choice, and you have full control of each and every aspect of your hardware and software stack.

The obvious downside is that building and maintaining your backend is an extremely time-consuming thing. This is a viable solution for a larger company with special requirements, applications with many data objects and tasks that require wide bandwidth like multimedia streaming.

Run Your Own Parse Server Instance

If you’re not that fond of tackling with hardware and adjusting load-balancing servers, it might be a good idea to deploy your own Parse Server to a cloud server. Thankfully, Parse has open-sourced it, so you can migrate data to your own MongoDB instance.

Unfortunately, not everything is working properly. Parse had lots of integrations like Facebook and Twitter login and third-party modules like Twilio or Mailchimp support, which won’t be available in Parse Server out of the box.

UPD: Parse Server now supports push notifications for iOS and Android!

The situation, however, may get better over time. In addition, Parse team is expected to open-source their awesome web admin dashboard, a place where you can rule everything.

Here’s how you can run your own parse instance in the cloud.

Heroku + MongoLab

If you’re after a simple and cheap alternative to Parse but don’t want to buy into another mBaaS, this one might be good for you. It’s definitely good for us, as that’s what Stanfy is going to do with current projects.

The main idea is that you can migrate your app from Parse to Parse Server by using a free Heroku instance and deploying your database to MongoLab.

Granted, this looks like yet another vendor-locked solution, however it brings more diversification than going for an alternative mBaaS. Moreover, Heroku doesn’t look like a project that’s about to go under in the near future.

Here’s a thoroughly crafted walkthrough on how to migrate your app to Parse Server using Heroku and MongoLab.

Microsoft Azure

Another cloud service you can choose to deploy your Parse Server instance to is Azure. You’d still need find a platform to run your MongoDB database–that could be MongoLab or any other one.

As many other Parse alternatives, the cloud by Microsoft is waiting for new users:

Azure App Service makes a great alternative for hosting your Parse server implementation. After all, the Node.js backend for Mobile Apps in Azure App Service is also an Express app. To make things even easier for you to get started, the Azure App Service team has created a streamlined provisioning process that makes it very easy to get your Parse server running in App Service.

If that sounds compelling to you, check out this migration guide.

Amazon Web Services

Another cloud solution popular among mobile app developers, AWS also sounds like a decent choice. There’s also a migration guide that outlines the benefits of going all Amazon in a rather authoritative manner:

Why AWS? It’s an enterprise-grade cloud platform which is miles ahead of competitors when it comes to features, price, and support. IMO if you’re not using Heroku (good for when you don’t want to manage anything) or bare metal (good for when you want to manage everything), you should be on AWS.

In addition to deploying Parse Server itself, you’ll need to get MongoDB running and set up Elastic Beanstalk, which is something like Heroku but compatible with all things AWS.

One Button To Rule Them All

Don’t want to read long tutorials? Community takes care of you! Deploy Parse Server to one of the above-mentioned clouds just tapping a button from ReadMe!

Go For Another mBaaS

Shutting down of Parse has definitely weakened developers’ faith in ready-made BaaS solutions.

“Fool me once, shame on you. Fool me twice, shame on me. There will be no “fool me three times”. Until mBaaS can come up with a credible response to the question of vendor lock-in, it’s dead. No sane developer would touch this now.” Tim Hampson on Quora

However, mBaaS is still good for lazy developers, pet projects and proof of concept apps that aren’t meant to be running for years to come. We’ve looked around and found a few good ones for you.

Apple CloudKit

Recently updated by Apple in the wake of the news of Parse shutting down, CloudKit in its current state looks like a good mBaaS for iOS applications.

Up until this week, developers using CloudKit could only access user data stored in iCloud from directly within the app. The last update, however, brought the possibility to “easily read and write to the CloudKit public database from a server-side process or script with a server-to-server key.”

Firebase

Acquired by Google in 2014, Firebase is a general BaaS platform for mobile and web apps that provides Android, iOS, and JavaScript SDKs. We featured Firebase earlier as one of the most interesting platforms for use with the Internet of Things.

The main issue of using Firebase as a backend for mobile apps used to be that it didn’t support push notifications. In early February, however, this issue was addressed by providing a way to integrate with Batch, a push notification backend that has already built a migration tool for Parse users.

Backendless

Another popular mBaaS solution, Backendless provides everything an app developer might want to see in a cloud backend. It includes push notifications, media streaming, geolocation, analytics dashboard, etc.

Same as many other mBaaS platforms, Backendless has already published a migration guide to make the transition easier for developers.

Moving on

Of course, it’s next to impossible to go over all the available alternatives to Parse. If you’re interested in digging deeper and discovering more service providers, both ready-made mBaaS and different DIY components, check out this crowdsourced list on GitHub and make your informed choice.

At the moment, it’s still unclear what solution will prevail and where the mobile app developers’ community will move. There’s still almost a year until Parse is fully shut down, and the landscape of its alternatives can change significantly.

Parse really solved lots of problems that are typical for different groups of customers, from students and startups to huge enterprise companies. We believe that at the end of the day every group will find its unique way of doing things.

Originally published at stanfy.com

If you enjoyed reading this, please click “Recommend”(the heart button) below.
This will help to share the story with others.

Read more:

• MadCode Meetup: Backend without code. Parse: Myth vs Reality
• Cloud Platforms for the Internet of Things
• 10 of the Best Mobile App Prototyping Tools
• Data Transfer Security for Mobile Apps

Life After Parse: What To Do Next? was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

That’s the follow-up of several talks about data protection for mobile applications I gave at the end of 2015. Geography is wide: twice in Ukraine (mdday.lviv.ua, CocoaHeads Kyiv #7); once in Amsterdam, Netherlands at do{iOS} conf; and in Minsk, Belarus at CocoaConfBy.

We, mobile app developers, usually consider security to be a complicated topic, and that is why security talks are rather tedious. I also watched lots of talks like those. While some security concepts are very difficult to understand, it’s also almost impossible to remember and implement them. I decided to take the other way round and make my talk about data protection easy to grasp, with a plenty of cute pictures.

Look on the slides, watch the video of my talk at do{iOS} conf, or read the whole story.

Real world security vs cyber world security

Let’s start with a real-world security. Meet two dodo birds: Alice and Bob. They are rare species and want to secure themselves from Eve, a Fennec Fox with looooong ears intended to listen all birds’ secrets. When birds notice Eve, they fly away to the bushes.

Well, in the real world things are clear: when somebody wants to hear your secrets — you can physically move away. Avoiding dangers is a part of our nature.

In the cyber world information security requires us to solve puzzling problems for which we don’t have intuitive instruments.

We only know the general direction:

• make communication confidential
• and limit access to the stored goods

It can be surprising, but every program is a potential target for attackers who will try to find a security vulnerabilities in our apps.

We — developers — are responsible for keeping things secure from bad guys.

We really care about users’ data. We want to protect data in the storage (saved to the database, files, NSUserDefaults, etc) and on it’s way from an app to a server.

Protect the data on its way to the server

Developers tend to think mobile apps are quite safe from malicious attacks in their neat sandboxed environments. This is only partially true: data-in-motion is still at risk, and the risk is high: all sorts of man-in-the-middle and passive eavesdropping attacks are still efficient, if you don’t protect the data the right way.

Why is this happening? Security is thought to be tangled and hard to implement. Instead of thinking about building the app based on the fundamental security principles, developers prefer to copy the quick solution from StackOverflow or to implement already existing cryptoalgorithms themselves. It leads to buggy software, full of vulnerabilities and security holes that can be easily cracked.

Thanks to the Apple ATS policies, now almost every iOS9 application uses HTTPS. HTTPS relies on SSL/TLS protocol, that — unfortunately — has a number of security issues and a lot of moving parts, which are easy to break.

Using HTTPS alone doesn’t make your app very secure: there are lots ways to break SSL encryption. From the attacker perspective, it looks like Alice wears a paper hat and Bob encircles himself with a handmade fence, and they feel secure. But they are not.

It’s very important to do SSL right to be more secure: disable old protocols (like sslv3), use long encryption keys and pin certificate inside the client. Well, you can read more in that tiny cheat sheet.

SSL pinning is one of the easiest things to implement inside iOS app that complicates MitM attacks. You just need to pin server’s certificate inside the app, encrypt it and store in a secure place. Well, of course, don’t forget to update certificate before it expires. Many apps are already using SSL pinning, for example, Paypal. As usual, there are amazing libs that can be helpful! For example, it takes only three lines of code on Swift to pin certificate using Pitaya lib.

But using SSL encryption is not enough. SSL was proven to have weak Forward Secrecy, which means that if the encryption key is leaked, all past and future(!) messages can be decrypted. Forward Secrecy is based on using ephemeral keys — keys that are constantly changing — and even if current key is revealed, only small portion of messages is decrypted.

Encrypting data with persistent keys causes the illusion of safety, but it’s just an illusion.

Always encrypt crucial data with ephemeral keys that are re-generated each session, and no one will be able to grab it using the soldering iron.

Before sending data, client and server negotiate about temporary key and use it only during current — rather short — session. Opening new session requires to generate new temporary key. It sounds quite tricky, but there are cool libs for that! Themis and OTRKit libs provide easy client and server interfaces to add encryption to your current client-server architecture.

Keep users data correctly

Okay, enough about data in motion, securing data in storage is also important. iOS has own crypto, protecting user’s data while your device is locked. But what if device is stolen and unlocked?

Wherever you store sensitive data, please, make sure it’s encrypted.

You don’t need to implement everything yourself. Realize possible security risks for your specific app, build the stout architecture based on CIA principle (confidentiality, integrity, authentication), use right tools, and own brains — this is a proper way to create the app that will take lots of time to break.

It’s quite simple: pick the good library, generate the encryption key (aka master password), encrypt data before writing to the storage, decrypt it after reading back. And of course, don’t put your master password plaintext inside your app or in the NSUserDefaults. Use Keychain (SSKeychain and Valet are nice wrappers) or generate master password ‘on the fly’ using custom math formula and KDF.

To summarize, securing your app is rather simple:

– use HTTPS and make sure you’ve disabled old and weak ciphers;
– implement SSL pinning, but encrypt the certificate and keep it safe;
– encrypt data in motion with the additional layer of encryption using the ephemeral keys;
– encrypt data before putting it in the storage and remember to store master key secure or to compute it “on the fly”.

What to see next

• Look at my slides to catch the full story.
• Read amazing blog posts by nabla-c0d3, pay attention on the audit of CryptoCat iOS app.
• Watch the great talk “Swift-ly Secure” by Seth Law.
• Follow Moxie Marlinspike and watch all his talks :)

Let me know if you care about security as much as I do =)

Data Protection For Mobile Client-Server Architectures was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the second part of post series “How to Estimate mobile projects”. Read also Part 1 — A step by step guide where we described the initial process of breaking down features and estimations.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

— Tom Cargill, Bell Labs

Changes and uncertainty

Sometimes, a project’s details change during development. Some changes are small (changing fonts or colors), some changes are large (adding an extra page or swapping screens). Changes themselves are not a problem, but they certainly affect the initial estimation. Sometimes, in order to make small changes, you need to rewrite a large piece of the system.

Read this developer horror story, which describes how many steps you need to take in order to change the text in the application that is already published in the AppStore.

The future changes are the things that nobody can estimate at the beginning of the project. Therefore, we must keep in mind that initial estimation becomes irrelevant when the project’s scope changes, which is the case in 90% of all projects.

Reinventing the wheel

The world of iOS development has lots of libraries that significantly reduce development time. We use libs like AFNetworking/RestKit, ReactiveCocoa, Runes, Themis, SDWebImage, SVProgressHUD, other UI controls, our own libs and so on. We can focus on the really interesting or complex components, and implement more valuable features before release. The more cool problem-solving libraries are in our arsenal, the more accurate our estimation is.

The mobile world is evolving so fast that we often google before implementing large components of the application, for example, how fast our favourite database is in the new version of iOS. Such research reduces the chance of stumbling upon unexpected problems during development and allows us to be in the know.

Some tasks are more time-consuming than they appear

Never underestimate the challenges that are associated with the real-world features. Among them are such things as time operations, especially with time zones, and specific hardware capabilities like cameras, GPS, push notifications or Bluetooth. It takes more time because development on a real device is “slightly” slower than on the simulator (although Apple tries to make our life easier every year).

In the same category we include integration with other physical devices such as an external microphone or smart watch.

Normally, embedding Apple services such as In-App purchasing and iAd doesn’t take a long time, and most developers think “it’s easy”, but it may take a long time to test, so we usually mark previously mentioned tasks as “time-consuming”.

In addition, the application won’t submit itself to the Store. We add several hours for submission to the overall estimated time. This is especially sad when you have to take lots and lots of screenshots for each localization, but now we can open up the fastlane tool, and things go much faster. Needless to say that it’s easy to forget something in the pre-release atmosphere, so we have created a ‘before submission checklist‘ to keep things in one place.

Must-have features that are always forgotten

What features are present on 80% of the applications, but are often forgotten during the estimation? Screens with a bunch of texts, such as the FAQ, TOS, license agreement and disclaimer. Alert-reminders asking users to rate an application and leave some comment in the store. A “contact us” button to send an email. These features are ‘easy’, but you should put them on the list, too.

Gathering usage statistics is very important in order to make the right decisions in the future. The simplest way is to track each screen opening and the pressing of every button. But sometimes you need to collect more complex events to calculate conversion or to understand whether the design works as expected. To do this, you need to think about what kind of events statistics will be useful and to integrate analytics tools (like Flurry, Google Analytics or Mixpanel).

Communication and documentation also take time

Developers usually estimate only the technical side of the story. Time spent on communication is also important. For example, often it’s necessary to design server-client API before starting the development phase, but sometimes API documentation is being designed on-the-fly. It takes time to coordinate teams, especially if they work remotely. In this case we don’t estimate ‘communication’, but ‘creating/updating API doc’.

According to the agile manifesto, working product is more important than comprehensive documentation, but it doesn’t mean that docs should not be created. When we estimate complicated features we don’t forget to add points to create the documentation. Talking about client-server interactions we often create sequence diagrams. Reading such diagrams instead of digging through the code trying to figure out what’s going on, saves hours, but creation of the diagram also takes time.

Unpredictable team factors

Teams make mistakes.

More often the team underestimates the complexity of the task, but sometimes they can overestimate it. A few tips on how to reduce this risk to a minimum.

Permanently increase the level of the team (gain more Exp!). More projects estimated and done means more XP gained. Besides, it is important to conduct the retrospective team meetings to try to figure out the reasons for inaccurate estimates.

Also, communicating with other teams, listening to their experience and mistakes, helps. And of course, reading a variety of developer resources daily or weekly to monitor community’s pitfalls and trends is also helpful.

Teams change.

Swapping horses when crossing a stream is obviously a bad idea. It’s not a developer’s fault if one team estimated the project, but another one is going to develop it.

Unfortunately, it happens. In this case, it is necessary to discuss and re-estimate the project with the new/updated team. Well, it seems like a waste of time, but in fact, it makes it easier to navigate in the project timeline and to understand the schedule before it gets too late.

Iterate and re-estimate

We talked about rough estimates in Part 1. In fact, agile project development involves continuous planning and evaluation sessions every sprint or two. Those features that were rough estimated should be re-estimated in more detail, taking into account the knowledge of the system that has emerged.

Features estimation, implementation, and estimation analysis are a part of the development cycle. The team gains XP and reduces the risks associated with every new project estimation.

Well,

in the developers’ world, there are many factors that affect the project’s estimation at the different stages. Unfortunately, it’s impossible to take all of them into account. Fortunately, we know many of these factors and know how to minimize risks.

On the one hand, it is crucial to improve the team constantly, creating various and complex projects, sharing practices with other teams and absorbing their experience. On the other hand, development should move by small iterations, constantly keeping one’s eye on the ball to see the possible divergences from the plan as early as possible.

Read More

Part 1 — How to Estimate Mobile Projects. A step by step guide

P.S.

Found useful? Enjoyed my pony sketches? Feel free to like and share post! :)

Originally published on Stanfy’s blog on October 12, 2015.

How to Estimate Mobile Projects 2. Why Estimation Fails and How to Prevent This was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the first part of articles series How to Estimate mobile projects. Read also Part 2 — Why Estimation Fails and How to Prevent This to learn about challenges and pitfalls that may occur.

If anyone asks two dev teams to estimate one project, most likely we will get two different estimates because each team’s judgement will be based on their experience and expertise.

In a perfect world, before engineers take off with an estimation,the project is already divided into functional modules, each is well-described, and interactions between them are documented, too. This project is evaluated by a team of experienced developers and they start development instantly. But the real world is not so rosy.

Start development from estimation

There is a widespread opinion that project estimations are a waste of time because they are very volatile in their nature: projects frequently turn out to be more challenging, new demands arrive, new features are added, members of the team come and go.

It is especially true in the case of a startup or an innovative project — where lots of things are to be validated or even completely pivoted. It’s hard to argue with harsh reality, but it’s always fun to look back at the end and realize how the project began and how naive we were.

Estimation of the project is the first step to a successful release.

The estimation is important: it explains how much time is needed to complete the project and get to release. It also helps to move from deliberation of the idea to the elaboration of the detailed plan; to estimate the complexity of system pieces; and to prioritize them.

Dig into the project’s problem domain

Here at Stanfy we estimate projects at different stages. The first stage is a rough estimation when the project only appears on the horizon. Here we explore the project’s industry (medicine, e-commerce, video streaming), and define users and what functions they may need.

We really need to understand the underlying domain and the problem we’re trying to solve.

At the rough estimation stage we devise how the user will work with the app and create the preliminary list of features. In order to make this list more accurate, we design low-fidelity wireframes, which show the user’s flow screen by screen inside the app. Wireframes allow us to put things in perspective: how the app’s features are correlated with the screens, and how the screens are connected to provide an intelligible user experience.

The next step is picking out the most tricky technological pieces: for example, whether the application has an offline mode with synchronization or a barcode scanner or live chat or video streaming. It allows us to understand what technological challenges may arise along the way, and what constraints we should keep in mind.

For example, integration with Spotlight Search is available only starting from iOS9; we should take this into account if we are going to create an app for iOS8, too. The more tricky features an application has, the more the roughly estimated time may differ from the actual one.

At this stage most customers think carefully about their lives, money and plans, and make a decision about whether they are ready to move forward or want to stop. After that comes Stage 2 of estimation, which we call ‘make it as accurate as you can’.

Design detailed screens

Having a detailed design is very important during the estimation phase. Steps to detailed screens are simple: low-fidelity wireframes, high-fidelity wireframe, interactive prototypes, designs. Lo-fi wireframes are created in the previous step, and they can be transformed into high-fidelity ones. Hi-fi wireframes show more details on the screen: layout, buttons, content placeholders. They pay respect to the design guidelines for every platform: hi-fi wireframes for iOS look different from those for Android.

Hi-fi wireframes can be easily transformed into interactive prototypes. One can open prototypes on mobile phones and interact with them like with real applications. Such prototypes are remarkably helpful for developers during the estimation phase; they help to understand an application’s navigation better and visualize its overall architecture.

Anyway, the result of estimating a project which has only wireframes — even interactive ones — is not completely accurate numbers.

The next stage is to transform wireframes into the set of designed screens. Looking at designs, developers understand the app even better: which components to use and whether it’s necessary to write custom elements or it’s enough to customise native ones.

A good design corresponds to guides: the Apple Human Interface Guidelines and the Android Design Guide. The sets of native components for the web, desktops and mobiles are each different, so if the designer uses complex or non-native components, it increases the resulting estimates. For example, the radio button is native for Web applications, but it has the analogues for mobile — a switch or toggle button. Nevertheless, estimating the prototypes is not as accurate as estimating already rendered designs.

Create a detailed feature list

It is hard to estimate the bare idea, so it’s necessary to create a features list or user stories that make up the project. Features are functional pieces that bring value to the user.

Describing features is something outside of the scope of the estimation and has to be done by the product owner’s team. Our development team clarifies and supplements the descriptions with the technical details.

For example, let’s consider a feature such as login via email. It consists of the login screen itself, keyboard behavior (it’s better to send data when the user presses the ‘done’ button on the keyboard than when he needs to hide the keyboard and look for the ‘send’ button behind it), data validation, sending requests to the server, handling responses, showing loading, showing error messages, etc.

Even the login feature that seemed so small hides many details, and a project is a set of such features. Usually we create a simple spreadsheet where features are divided into blocks, with less or more detailed descriptions of each.

Estimate effort

To estimate the feature means to find efforts (time and cost) that are required to get this feature done. There are different methods of estimation, but we use analogy based estimation, correlating the feature with its difficulty: easy, normal, hard, infinity — like game levels!

Let’s see examples.

• Easy: Login, forgot password, FAQ, help screens. Usually, static or dynamic screens, without too complex a design, often without sending requests to the server.
• Normal: Home screen, registration, tables, collections, custom controls. Usual screens with server requests, or custom controls.
• Hard: Third-party API integration, audio/video recording, streaming, chatting, custom gestures, synchronization, offline mode.
• Extreme. Usually they’re unclear and huge features. It’s better to divide them into smaller ones.

Sometimes it’s hard to define where the line is between groups. The rule is simple: round upward if you have doubts.

Let’s look at an example. Almost every mobile application uses tableview to show content: like showing tweets or cat photos. In the mobile world, the table is a list of the cells, which contain texts, pictures, dates and so on.

A table may look very simple, but from a developer’s perspective a simple table involves:

• Design cells (which can contain a lot of information and extra buttons and have flexible content depending on height).
• Loading data (send requests to the server, parse response, create data models)
• Loading more, pull-down-to-refresh.
• Showing loading, empty, and error states (like connection errors).
• Adding/removing items from the table. In my experience, removing items from the table can be very tricky — many apps crash due to data inconsistency.
• Merging content. Sometimes you will need to merge local content with data from the server.
• User interaction when tapping on the cell itself or on a button on the cell (usually the background changes to indicate the selected state and a new screen opens).
• Image caching for pictures in cells (if any).
• Nice animation when cells appear on the screen while scrolling (image fading or light bouncing, depending on the project style).

Looks complicated, right? And after all, a table should look nice and be scrolled smoothly.

But the good thing is that most of these features only need to be written once and can be reused with different tables inside one project or in different projects.

We are working on the list of components that are frequently used in many mobile applications, describing different user scenarios and corner cases. It’s useful to have this list on hand during project estimation to keep in mind unique peculiarities of every component.

The result of this stage is the list of the estimated features. The more hard or even ‘extreme’ features there are in the list, the more time the project takes.

Sort features by priority

Some features are more important than others. Therefore, we divide them into “must have”, “nice to have” and “cool, but later.” “Must-haves” are core features — without them the application won’t serve its purpose.

This technique is called the MoSCoW method; it allows you to focus on the most important requirements to provide users a valuable product as soon as possible.

Prioritizing has to be done by the product owner’s team right after creating the features list. Priorities help developers to focus on the most important features (without spending time on the deep study and evaluation of the features in the bottom of the icebox).

If we are talking about a chat application, for example, then the chatting itself is a core feature, but stickers’ support and sending audio messages can be added in the next release.

Often, a list of “cool but later” features is changed right after the first release when users give their feedback. It may turn out they really want a geolocation function to share with friends, and stickers can be postponed.

R&D features

Of course, there are features that we can’t estimate the value of at first. For such features, we do a little research, google and collect links to understand which way to go and what to expect. At the end of the estimation phase, we highlight such R&D features and consider that they may increase the overall estimated time.

For example, the integration with not very popular third-party services could be rather tricky. If a service is well documented, just to integrate it and be sure that it works correctly can make up around 20% of the overall work. But often, ‘correctly’ doesn’t mean ‘good enough’ — and you devote the remaining 80% of the time to customizing, improving or even hacking your app.

Do not estimate tech practices!

Some things we do not add to the features list even though we do them during development. Among these are engineering practices such as pair programming or writing tests on business logic or backend API. We also “automatically” integrate crash analytics tools (like Crashlytics) and use the continuous integration/continuous delivery services to regularly build and deliver the latest version of the app.

The time is required to set up such things, but usually this time is generously repaid even before the product is released. For example, first we must spend some time to obtain keys from the crash detecting system and configure your application to use them; but then analyzing the crash reports may save you an unbelievable amount of time in finding and fixing crashes before users notice them.

Solutions instead of the problems

During the estimation phase, understanding the challenges ahead is to some extent guesswork, as no problem is a real problem yet, and you have plenty of time to plan, simplify features, reiterate design and proceed on a clear path. If the proposed budget or schedule seems inadequate to do the work, we propose adjusting upward or downward the cost, schedule or features.

In essence, planning is about trying to understand the challenges ahead beforehand. In good teams, it is each member’s responsibility to maintain a special tone during estimations — talk about solutions to ‘possible problems’, not about ‘these monsters ahead’.

So,

the estimation process is a team job: the client describes his own vision, the product owner’s team clarifies the idea and creates and prioritizes the features list. Developers are immersed in the project area, trying to find out as much as possible about the project and the end-users. They estimate features, adding a technical point of view and trying not to forget anything.

Some features are typical for many applications, so they are easier to estimate (for example, you can like posts in almost every social app). It’s more complicated to estimate unique features that no one else has done before. Of course, much depends on the experience of the team and how many different unique applications they have developed.

Read more

Part 2 — Why Estimation Fails and How to Prevent This

P.S.

Found useful? Enjoyed my pony sketches? Feel free to like and share post! :)

Originally published on Stanfy’s blog on October 12, 2015.

How to Estimate Mobile Projects 1. A Step by Step Guide was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re developing an application that cares about users really much: users shouldn’t see any offensive texts there. But checking every post by a live moderator takes a lot of time and reduces the application responsiveness.

We’ve created a “live” filter inside the app that is completely invisible, as long as the user’s text does not contain offensive words. If the filter finds something rude, it gently hints user about wicked content.

Of course, every filter can be broken, so, in addition, the app has ‘flag abuse’ feature for users to mark inappropriate content.

Creating profanity filter is quite interesting and tricky task. We found lots of corner cases and learned many dirty words :)

I’ve described the evolution of the filter rules in my slides with more techy examples :)

☝️Attention! 18+. Lot of dirty words below :)

P.S.

Tap on pictures to play demo and find secret content 🤐

P.P.S.

Originally published on Stanfy’s blog on September 10, 2015.

If you liked the article, hit that heart button below. Would mean a lot to me. :)

Building Profanity Filters: clbuttic sh!t was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

While we are waiting for Brillo’s release, let’s look at how we can use a standard Android as an embedded operating system for the next generation of devices. Let’s assume that we need to design and manufacture a new hardware device in non-mobile categories like smart photo frames, smart projectors, smart mirrors, smart TV top boxes, etc. The question is: Is it worth selecting Android as the embedded operating system for your next device?

Good things about using embedded Android (Pros)

There are definitely more good things than bad about using Android as an embedded OS for a custom made device.

1. Easy UI customization.

Many graphics libraries are available for a fast UI development.

2. A large and growing community of Android developers.

Google is pushing Android everywhere (smartphones, smartwatches, cars, tablets, TVs) and encourages developers to create custom apps for each device. Besides having this extended ecosystem, Google also invests in the education and training of Android developers with the Udacity Android Nanodegree.

The Android ecosystem is growing.

So it is safe to assume that it will not be a problem to find a decent Android developer for your custom app development or even for extending your device to a full featured ecosystem later.

3. Linux based.

Android is running on top of Linux Kernel. Most drivers for Android devices are actually Linux drivers. It is handy when you need to integrate custom hardware modules and can use Linux drivers for that

4. Great developer tools.

The Android Studio, fully provided with features, has everything needed, like Code Editors, Graphical Layout Editors, Debuggers. Not everything will work for low level Kernel or NDK developments, but still it is great for the overall ecosystem and custom app developers.

5. Reduces time to market.

It is easier to start with Android than with a Linux distro because it is easy to customize the UI and to find developers for it. Great tools and community help to move fast and deliver products to market early.

Things to keep in mind about embedded Android (Cons)

All good things have their price, so there are some issues that may arise when using Android as an embedded OS in non-mobile hardware devices.

1. It is resource heavy

It requires about 512MB of RAM and a CPU with about 1GHz, so it is definitely not for small and power-efficient devices that should last months on a single battery charge. But Android Wear on smartwatches has shown us that it is moving toward miniaturization as well.

2. Hard to update OS to the newest version

Usually board vendors don’t provide updates for the new Android and support only a few current versions. It means that you are on your own with the updates to the new OS version release that is not an easy task, especially if you’ve already made changes in the system services and have some manually integrated drivers.

3. No Google products available without an agreement with Google

This means that you cannot use automatic platform updates distributed as an APK through the Google Play store. No Google Maps or Google+ services either.

Final thoughts

Android is a ubiquitous OS that becomes available on more and more devices, from smartphones to smart cars. It has the backing of Google, is used by myriad hardware manufacturers and has the constantly growing Android community.

Many developer tools and the growing community of Android developers make it easy to build your product quickly and reduce the time to market. And with the release of Brillo later this year we will have even more possibilities for extending Android to even more embedded devices.

What do you think about using embedded Android in non-mobile devices?

If you need help with development of your custom Android Firmware — let us know!

Other useful links:

• Fixing up a custom Android build: Pitfalls and possibilities
• Android Compatibility Definition

Originally published at stanfy.com on October 15, 2015.

If you liked the article, hit that heart button below. Would mean a lot to me. :)

Pros and Cons of Using Embedded Android for a Non-Mobile Device was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

—

Hi there. I hope that you’ve already read the previous post about why you shouldn’t show spinners in your applications, and how you can actually avoid it.

Let’s recap a few things here. Our main goal is to allow the user to feel that every action she performs in the application happens immediately, blazingly fast, even if some actions are performed slowly. We’ll be working with non-confirmed operations here a lot, so we cannot use this approach if we’re about to work with highly-sensitive data, such as credit card information, payment information, etc.

Previously we mentioned that in order to make an application look faster, we can predict some operations and show the results to the user without receiving actual confirmation from the server. Despite the fact that there is always a delay when an application communicates with the server, we were able to successfully hide that from the users.

However, this will work well only for simple situations, when the user doesn’t perform actions too quickly, and when we’re actually able to perform them fast enough and not bother about cases, where multiple concurrent operations are performed on the same object. In case there are multiple operations performed, we’ll need something a bit more complex than a simple optimistic model.

Let’s consider the following example. The user is working with an object (let’s say a post) and every operation she performs needs to be confirmed by the server.

So here is a list of actions that the user performs:

• likes the post
• adds a comment to the post
• changes post rating from 2 to 5
• unlikes the post
• updates the title to “Handling multiple interactions without server confirmation”
• changes the post rating from 5 to 2
• changes post rating from 2 to 4
• likes the post

Let’s say that there’s no such thing as a “Save button” on the screen, and the user expects that every change she makes will be automatically saved at some point. Also, let’s imagine that we cannot wait until the user finishes all his operations (In real life we could probably wait some time before sending a request to the server, then group changes that the user has made, and only then send a request).

Base implementation of this logic can be described like so: Just send the update once the user changes something, and show the results from the server. This implementation often leads to blinking and showing incorrect (from the user perspective, but 100% confirmed on the server side) information to the user.

It probably still can work fine… until operations start to fail.

If we aren’t using an optimistic model, it will be hell; the only thing you can do then is to tell the user “Sorry, something went wrong; please revise all the changes you’ve made in the last four minutes, and check to see if everything looks fine.” Some application decides to show tons of alerts — for each failed operation.

But even using the optimistic model, it’s hard to correctly handle this situation. If there are a lot of operations, we would have a state based on unapproved states and this chain will break. :(

Storing confirmed object and updates

In order to handle those situations, we could use another trick — first, we need some Model in our application which can calculate the state of the object by giving the model a Starting state and list of operations which should be performed on that object.

Next, when an operation is performed on the object, we add this operation to the list of unconfirmed operations, and recalculate the current object state. Once the operation succeeds, we should update the confirmed object and remove the finished operation from the list, and then recalculate the state again. If the operation fails, we just need to remove this operation from the list and recalculate the visible state.

That’s all. Just by adding this one simple rule, we can correctly rollback our failed operations.

Queueing updates

In order to simplify your life, I highly recommend preventing concurrent updates on the object. On one hand it will require having some queue for each object, but on the other hand it will allow you to handle complex cases faster.

Grouping and discarding operations

When we have list of operations that need to be performed on the object, we can simply run them on the server one by one, and update the visual state correspondingly, using the confirmed object + set of operations which are left.

If we know that a list of operations can become too big, we could start to use some optimisations in order to decrease it.

Take a look at the previous example, with the post. What can we change there?

• If our server accepts object updates and we can send the whole object with changes, we would next: {like}, {comment:, rating:4, title:”title”}.

• If our server doesn’t accept object updates and works per property basis, we still have some things to optimise.

Retrying operations

We can add one more thing — if the operation fails, we won’t throw it away immediately. Instead, we would retry it again a few times after some delays (Actually, it’s good to have this optimisation even if we’re not using optimistic models). :)

We can go even further. Instead of blindly repeating the same operation, upon operation failure, we can check whether or not the result of this operation was already overridden by the next operations. If so, we can throw away the current operation and start the next one.

Sum up

We’re often bound to the servers in our applications. The server is the king. The server decides what to do, what the current state is, and how to perform complex business logic. Often the connection to that server isn’t fast and not reliable enough. By moving some parts of simple logic on the client side, we shouldn’t often have to wait for confirmations and can go on even without server confirmation.

P.S

This article was intended to be published long time ago, and since then a lot of things happened. One of them is that Parse has revealed their SDK source, and there you can find, that some operations are performed in the way, similar to described in this article. Still, I decided to publish this article, may be not everyone have looked to the Parse sources yet :))

P.P.S

This is technically repost of the post that was written on Stanfy’s blog. But since there are a lot of people who are following me on Medium, I will repost all my posts here too. :) (I don’t like the idea how Medium works with comments, so better ask me questions in the blog)

If you liked the article, hit that heart button below. Would mean a lot to me. :)

Optimistic Models 2 — Handling multiple interactions without server confirmation was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s take a regular light bulb — one of the most highly commoditized products on the market. At least it used to be so until LED technology gained traction and now we are looking at forecasts of 45% growth per year through 2020 in LEDs. Markets appear to be moving toward LEDs replacing 100% of existing technology including incandescent bulbs. At the same time, the whole new segment of smart home appliances, especially the smart light bulbs, emerged with the introduction of Philips Hue in 2012.

Now we are seeing dozens of smart light bulbs on the market with new players launching a crowdfunding campaign on Kickstarter or Indiegogo every other month. Let’s pretend we need to build our own smart light bulb and think about how to connect it to the Internet and to the user.

High Level Architecture for a Connected Smart Light Bulb

There are different ways to connect a light bulb to a smartphone and/or the Internet: smartphone dependent or smartphone independent; direct connection over Bluetooth/Wi-Fi; or connection through the hub.

1. Smartphone Centric Architecture (with or without cloud)

In smartphone-centric architecture a light bulb is connected directly to a smartphone via Bluetooth. Thus the light bulb doesn’t have a direct link to the Internet and depends on the proximity of the smartphone.

In this case the connection of the light bulb to the Internet is possible only through the smartphone. Consequently any smart feature that relies on the Internet is available only in close proximity to the smartphone. It’s like triggering an IFTTT action only when the smartphone is present in a Bluetooth range (up to 100 meters), because without the smartphone there is no connection from IFTTT to the light bulb.

The definite advantage of this architecture for customers is that they don’t need an additional device or hub for the light bulb to be connected but can control it from the smartphone. Furthermore, the setup process is quite easy and straightforward for the user, but it comes at the cost of dependency on a smartphone in order to connect to the Internet.

2. Hub-centric Architecture (with or without cloud)

The Hub in hub-centric architecture is working as an intermediary for connecting a bulb to the smartphone and to the Internet, since it usually connects to the home Wi-Fi or Ethernet network. A smart lightbulb is totally independent of a smartphone and could be smart on it’s own.

With the hub-centric architecture it is easier to organize the grouping and seamless connection of the many light bulbs and other appliances in a house. Every connected device can be controlled from anywhere and at any time. Background smart triggers, from integrations to the third party services (IFTTT, stock market dynamics, etc), are easily achievable, as well as controlling lights from any smartphone belonging to the home owners.

A device cloud in this architecture is optional because many smart features could be set up without having a dedicated cloud infrastructure. But with a cloud features become more robust and reliable because there is a lot more computational power available in a cloud for complex tasks than on a hub device itself.

The drawback of hub-centric architecture lies in the need to add another device to the system that needs to be delivered to the customer’s home and installed correctly.

And this is also the architecture broadly used by Google, Apple and Amazon in approaching the smart home market today. Read more on their hubs below.

3. Cloud Centric Architecture (without hub)

In the Cloud-centric architecture without hub we have a smart device that is directly connected to the home Wi-Fi network and doesn’t need any additional hub to work. It has a simple setup process for the customer and looks similar to the Smartphone Centric Architecture but with the benefit of a direct and constant connection of the device to the Internet.

Sometimes this architecture becomes similar to the Hub centric architecture in that there is a Master-Slave relationship organized with similar smart devices. The master device is connected to the internet through the Wi-Fi network and other devices are connected to the master and to one another with the mesh network (802.15.4, 6LoWPAN, etc).

The good thing about this architecture is that there is no need to buy and install additional devices (like with the Hub) while retaining a constant and independent connection to the Internet.

Smart Home Ecosystem Wars: Android Brillo + Weave vs HomeKit vs Amazon Echo

There is a constant battle of ecosystem platforms designed to organize and connect our home appliances. Such a platform is a necessary and required step before we can invent and build more services on top of the connected smart home devices.

Google and Apple are moving towards the Hub centric architecture with OnHub and Apple TV respectively. They both also have their own infrastructure ecosystems (Brillo + Weave from Google and HomeKit from Apple) that are aiming to keep customers locked within their walled gardens. Such an approach will allow Google and Apple to have full control over your home, know everything about you and your family and provide added services to you for an additional cost. This will be a good scenario with a recurring business model for them.

Amazon is also trying to build the same ecosystem with Amazon Echo and a fleet of third party connected hardware appliance. Eventually the result will be the same locked ecosystem for the consumer in which she can use content and services and buy her household products from Amazon. Another great concept from Amazon, which is currently tested only with its Prime Members, is the Amazon Dash buttons that allow users to buy products with literally one click of a button that is attached to a wall in the kitchen or bathroom.

As we can see, there is a real race between major players to connect all the appliances in our homes. They want to connect every device to businesses, services and people to provide a real value for us. Of course, this is in exchange for the data and opportunity to subscribe you to the recurring paid services.

UPDATE: While this article was being written, Amazon released the Lightning API for the Amazon Echo, which lets customers control lights and switches by speaking a command. If you are a smart light bulb developer you can benefit from such integration, which increases interoperability and gives a customer more options when using the device.

Final Thoughts about Smart Light Bulb Development

Having said everything about connected objects let’s make a final list of thoughts that could help you design and make a decision about a great smart light bulb product and other connected objects.

1. Independent connection to the Internet creates the possibility to connect the outer world with your home. Better not to lock a device into a direct connection with the smartphone, because eventually all devices should be connected the third-party services and businesses to attract customers.
2. Integration with big players’ ecosystems like Google Brillo, Apple HomeKit, Amazon Echo will leverage the power of common infrastructure and unlock interoperability with other smart things.
3. Open developer API from day one and build a community of makers, businesses and people around your smart device product.

Let’s make the connected world seamlessly integrated with businesses and people.

If you like this article please help to spread the word about it and Recommend it. Thanks!

Stanfy is a team of passionate software developers and engineers that works in mobile and IoT and can help you to go through the necessary steps of software engineering, from prototyping and manufacturing to the market. Let’s talk.

Originally published at stanfy.com on September 1, 2015.

3 Types of Software Architecture for Connected Devices. A Smart Light Bulb Case was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, we are writing applications. And each application is connected to the Internet. Let’s just talk about those applications which are connected to the Internet. Often, when users perform some operation in the application, a server response is needed, so while this response is being performed, the user is staring at this:

There’s no problem with that if you really need to have a server response, and you need to have 100% correct data only. But the thing is that there are a lot of times when we can easily avoid showing the spinner to the user, and trick the user, showing him what he wants to see rather than showing spinners during every user interaction, even if those spinners are cute.

Types of user interaction

Let’s look at user interactions from the perspective of user expectations. When doing some operations in the application, the user can’t be sure about the result — before a publication is opened, it’s hard to predict its contents. On the other hand, some operations are highly predictable for the user:

• liking a favorite post
• writing a comment
• following/unfollowing another user

Often all these operations require an internet connection in order to be executed, and in badly designed applications, we often see a spinner after each operation. In very badly designed applications, we see a spinner which locks the whole application screen (and which we don’t have the ability to cancel).

Idea

Somehow we need to convince the user that these operations are performing immediately. And here we’ll explain how we do that in our applications.

This approach doesn’t require big architecture solutions from the start and can be implemented at any moment of the application development cycle, without any harm to the original. Still, there are few things which are not required, but highly recommended. These things aren’t new and you can find a lot of information about how to use them correctly and why you need to have them in your application.

Requirements

View Layer without logic

Taken from MVVM pattern. The main idea is that the View Layer doesn’t know anything about your business logic. All that this View Layer should care about are simple, plain objects, which have no business logic in them, or at least the View Layer shouldn’t know anything about it:

Updateable View Layer

The View layer should reflect any data changes that are performed in the data it renders. Let’s say a person’s name was changed. Your view should behave correctly, and be able to update itself when this happens. In our examples UIViewController will be the object which will respond to the changes in the model and will tell View to update itself with new data.

Request Manager

This is the object that is responsible for network operations in your application. You should have one (I hope you do). Also, it’s even better if your ViewController speaks with the Model layer, and the Model layer itself speaks with Request Manager. Again, this is not required, but this is how it works in our applications.

Application Structure

Here’s how(probably) your application works now. This is waaay too schematic, but you can update it with your own Structural Units.

So here’s what happens:

• Model gets the data from internet
• ViewController listens to the data from Model and updates View
• User Performs some Action on the View
• Spinner starts
• View Controller tells Model to handle action
• Model goes to the internet(to the server, for example)
• Model gets response from the server
• ViewController’s callback got called
• ViewController updates view
• Spinner stops

Let’s add one small thing

In order to trick the user we’ll need to have just one simple thing — the Optimistic Model.

Optimistic Model

The idea behind that is pretty straightforward. When the user changes something, the optimistic model gets the original object, tries to predict the potential result, then calls ViewController’s callback with this updated object, and then performs the actual operation in the background like the default Model. Once the real result is returned from the server, the optimistic model calls callback with the real object, or in case of an error, the Model performs callback with the original object and then calls error callback.

If we highlight possible flows, they can look like this:

Optimistic Model Implementation

Now, let’s look how the Optimistic Model implementation can look like

With this simple update we were able to perform network operations “immediately” (at least from the user perspective).

Let’s Summarize

What do we have as the result?

• A happy user who doesn’t need to wait for each operation to finish:)
• A happy user, who thinks that your application is blazingly fast(even if your server is really slow).

Notes

• In the example, we’re copying the object. This is done to prevent some unexpected changes, which can occur, for example, when there are other references on this object in the application.
• In the example, in server response, we have a fully updated object. In the real world application, this rarely true. Anyway, even if server responds with partial updates, this approach can work correctly.
• The Optimistic Model can be simply used for independent properties or groups of properties of object.
• Depending on your needs, you probably would need to have Local Storage, which will store data that has not been sent to the server yet.
• In complex case, when user tries to perform different operations quickly on the same object, you will probably need to use Temporary/Shadow Storage, which will decide what to show. An example of the implementation of this object will be covered in next post.

P.S.

Now, press “recommend” button, and measure how long it takes to perform one simple action. Do you see the spinner there? :) So why would you put spinners in your application?

Stanfy is an agile software development company. We help others evaluate technology, develop and deploy software systems that tuned to work in mobile and wearable world. Drop us a line if you need a collaboration on your lean technology product or startup.

Do not let your user see spinners was originally published in Stanfy Engineering Practices on Medium, where people are continuing the conversation by highlighting and responding to this story.