via iOS9 Day-by-Day :: Day 9 :: UIKit Dynamics.
his post is part of the iOS9 Day-by-Day blog series. More details can be found on the index page.
UIKit Dynamics was introduced in iOS 7, to give developers an easy way to add some physical realism to their user interfaces. iOS 9 has brought a couple of big improvements and we are going to take a look at some of these in this post.
via Customizing UIKit appearance using protocols #ProtocolUI · central_<br/>dispatch.
I remeber exactly the very moment when I started hating storyboards. It was back in 2013, and I had to solve my first storyboard merge conflict. I didn’t succeed. I convinced myself that storyboards are tools for beginners because “real programmers write code.” We even had it written in our iOS coding guidelines at STRV: “unless the app is super simple, try to avoid using storyboards.”
It all changed with iOS 8, the iPhone6 and all these different screen sizes we had to support. I started using storyboards, and within a few weeks, I realized how powerful a tool it is. I fell in love. Of course, you can still write all your constraints for different size classes in code. But let’s face it, it’s not a way how to do an easily maintainable piece of software.
via Creating a Custom UIkit Theme with Gulp and Less.
Everyone wants to be unique. I guess you won’t be super happy if in your surroundings there are many people looking just like you, right? This holds true for the other people too. Your friends also won’t be happy to see clones of you everywhere. The same is true for our websites.
Nowadays, building a website with a front-end framework is common. The problem though is that many people blame such frameworks for making all websites “look the same”. But the tool isn’t to blame if developers aren’t willing to make the necessary customizations.
For those of you who want the websites you build to stand out from the crowd, I’ll demonstrate how you can use UIkit’s Customizer to create different themes and theme variations (styles). The process is straightforward, but you need a proper workflow to do it with a minimum amount of headache.
via Building Cross Platform Applications Overview – Xamarin.
This guide introduces the Xamarin platform and how to architect a cross-platform application to maximize code re-use and deliver a high-quality native experience on all of the main mobile platforms: iOS, Android and Windows Phone.
The approach used in this document is generally applicable to both productivity apps and game apps, however the focus is on productivity and utility (non-game applications). See the [Introduction to MonoGame document] for cross-platform game development guidance.
The phrase “write-once, run everywhere” is often used to extol the virtues of a single codebase that runs unmodified on multiple platforms. While it has the benefit of code re-use, that approach often leads to applications that have a lowest-common-denominator feature-set and a generic-looking user interface that does not fit nicely into any of the target platforms.
Xamarin is not just a “write-once, run everywhere” platform, because one of its strengths is the ability to implement native user interfaces specifically for each platform. However, with thoughtful design it’s still possible to share most of the non-user interface code and get the best of both worlds: write your data storage and business logic code once, and present native UIs on each platform. This document discusses a general architectural approach to achieve this goal.
Here is a summary of the key points for creating Xamarin cross-platform apps:
- Use C# – Write your apps in C#. Existing code written in C# can be ported to iOS and Android using Xamarin very easily, and obviously used on Windows Phone.
- Utilize the MVC design pattern – Develop your application’s User Interface using the Model/View/Controller pattern. Architect your application using a Model/View/Controller approach or a Model/View/ViewModel approach where there is a clear separation between the “Model” and the rest. Determine which parts of your application will be using native user interface elements of each platform (iOS, Android, Windows Phone and Windows 8/RT) and use this as a guideline to split your application into two components: “Core” and “User-Interface”.
- Build native UIs – Each OS-specific application provides a different user-interface layer (implemented in C# with the assistance of native UI design tools):
- On iOS, use the MonoTouch.UIKit APIs to create native-looking applications, optionally utilizing Xamarin’s iOS designer to create your UI visually.
- On Android, use Android.Views to create native-looking applications, taking advantage of Xamarin’s UI designer
- On Windows Phone you will be using the XAML/Silverlight presentation layer, using Visual Studio or Blend’s UI designer
- On Windows 8, use the Metro APIs to create a native user experience.
The amount of code re-use will depend largely on how much code is kept in the shared core and how much code is user-interface specific. The core code is anything that does not interact directly with the user, but instead provides services for parts of the application that will collect and display this information.
To increase the amount of code re-use, you can adopt cross-platform components that provide common services across all these systems such as:
- SQLite-NET for local SQL storage,
- Xamarin.Mobile for accessing device-specific capabilities including the camera, contacts and geolocation,
- Using framework features for networking, web services, IO and more.
Some of these components are implemented in the Tasky case study.
via A First Look at UIStackView in Swift 2.0.
Amongst the many exciting things here at WWDC (Metal for OS X, UI Debugging, Open Source Swift…) is the introduction of a new layout class for Swift, UIStackView. UIStackView is a great addition to UIKit which offers a really simple way to leverage Auto Layout by arranging its subviews in rows or columns.
It’s a bittersweet addition for me, since my very own Shinpuru Layout components did pretty much the same. That said, UIStackView contains a lot more functionality and is undoubtedly more performant than my code.
I’ve created a little Swift 2.0 application that demonstrates a few features of UIStackView: it dynamically sizes a handful of coloured boxes, changes layout directions based on orientation and allows the user to add or remove those boxes with a nice animation. To run this code, you’ll need Xcode 7.
The application contains three UIStackView instances: mainStackView is always laid out vertically and containsstackView and a UISegmentedControl. stackView contains purple, red and blue boxes and subStackView which, in turn, contains grey, yellow and green boxes.
via Technical Note TN2239: iOS Debugging Magic.
iOS contains a number of ‘secret’ debugging facilities, including environment variables, preferences, routines callable from GDB, and so on. This technote describes these facilities. If you’re developing for iOS, you should look through this list to see if you’re missing out on something that will make your life easier.
via Reusing views in storyboards with Auto Layout — Cocoanuts iOS Blog.
For the past few months, I have been working on a rather big project using storyboards and Auto Layout. This has been a great learning experience, and I think I now have a much better understanding of the pros and cons of using Interface Builder vs. pure code. Half a year ago I still assumed that at some point a clear winner would emerge, or at least I would end up preferring one approach over the other. But today I find myself switching between these approaches depending on the project, or even mixing them within a single project. It usually depends on subtle things like the complexity of your application flow and the inheritance relationships between your view controllers.
In any case, I think being able to work with Interface Builder and Auto Layout is an important skill to have as an iOS developer. The first time you try to set up constraints for a non-trivial view hierarchy can be a frustrating experience, and your productivity will probably first take a hit when you start working with storyboards, but you end up with some valuable new tools in your belt and a much better understanding of UIKit, if nothing else. I plan to write more about this topic in the coming months, but today I would like to focus on reusable views in the context of storyboards and Auto Layout.