It’s always hard to answer it because preferences tend to vary even among members of the most closely-knit teams. However, enforcing a consistent approach to the way UI flow is handled within an app almost always results in higher quality of the project.
Every decision of this magnitude requires the team to take a closer look at the pros and cons (or tradeoffs 🙅) of all available solutions. This article discusses the majority of the known (and popular) ways of dealing with UI flow management to help you choose the one that fits your or your team’s goals the best.
The beginning of the year is always a good moment to look back and get a new, fresh perspective on things past. 2015 was truly a great year for designers and developers, and with widespread adoption of collaborative software like InVision and Slack, more amazing products got shipped faster and in a more effective manner. Looking forward to all the things that 2016 has in store for us, we prepared a short list of events that had the most profound impact on the industry in 2015:
Continuous Integration (CI) and Continuous Delivery (CD) are both relatively fresh practices in our, iOS developers’ that is, toolkits. This is mostly because we didn’t really have good tools to facilitate their proper deployment until recently. Gone are the days of breaking the build or tests without even noticing. Forget about archiving and sending builds manually to your testers or clients. Build servers are here to save us from the mundane toil.
The process of setting up our build server will consist of two steps:
Continuous Integration: First, we’ll set up Travis CI to run our test suite on each pull request. This will allow us to be sure that neither a build nor tests will break after merging with the main branch (develop in our case). One cool thing here: Travis CI doesn’t actually use the branch a pull request is based on. Instead, it merges it with develop first and then uses this temporary branch.
Continuous Delivery: Then, we’ll set up Travis CI to build, archive, and push a build to HockeyApp after each commit is pushed to (or merged to) develop. This will allow all interested parties to always be able to get the latest build of the app. We’ll also show how to set up the same capability on our local machine.
The knowledge collected and presented in this article is derived from other sourcesavailableonline. Given some of the most common reactions 👏 in our team after one of us manages to set up CI & CD, I came to the conclusion that there’s real value in getting every little detail about their deployment covered in a single piece.