Do the right way with Team work
Mobile App and Team work with component development
You can do the whole lot from server end, database, middleware to frontend. However, you cannot handle the workload of the team. What if you face 4,5 systems same time? What if each system requires 20, 30 screens or components? What if you find many components can be used across the apps?
Team work
The idea is the whole team will work together to analyse the many apps to determine the components that will be self-assigned to the team members.
To illustrate the idea, we take a web site as an example.
To avoid the infliction between developers, you will need to build the screen independent to others, so that developers can work in parallel.
Often, you will make screen and its function in folder. For examples, under folder profile you would have
js/profile.js
css/profile.css
images/pic1.png …
profile.html // the profile screen itself to be called by the parent
index.html //the screen to call up the profile for local development
…
The parent index.html will most likely dynamic load the profile with $(“container”).load(“profile/profile.html #subContainer”), not to preload to save memory and loading time for the main website.
By doing this, you are doing component development for your application. Please refer to the previous article “Do the right way with Component”. The work looks like this
Mobile App
You dont do 30 screen app too often. However, when people want to change their web app to native, you might come across something like this
It is not a simple work, as the logic of web app is not quite the same of native app. In native app, we use the IOS framework and inherited down the classes for customizing them. Therefore, the wireframe products on market, stick with Apple look and feel, while those converted from Web apps tend not to be in that trending.
In certain limit, it is acceptable for custom classes approach since it might make your app standing out, just that the fancy apps will have more chance to get rejected by AppStore. The mystery in AppStore was discussed in “Undocumented Appstore”.
The wireframe of native app could look like this
The way we work with mobile app is very much the same of above with team work. We do component as discussed in previous article “Do the right way with Component”. Very much the same, we put all files belong to the component under a folder. Under the folder profile, there will be files like this
1- ProfileViewController.swift // control and model
2- ProfileViewController.storyboard // view
3- profileViewControllerPickerExt.swift // for picker extension
4- …
The local project that direct accesses the profile folder is profileUI.xcodeproj. it also has it own viewController and storyboard. The main storyboard is an empty view with one button to call up the profile. There is reason for this structure, as all the development, debug, changes are in this local project.
The parent project will have read only access to the profile folder and call it as a blackbox. The concept of “blackbox” has been discussed earlier. The parent project wont make any direct change to the profile component. However, any further changes in the profile sub project will automatically reflect to all the apps that use the profile component.
Component Structure
You will find all components are structured in the same way. A project that has an one button screen, that calls the component in its folder, that has the swift file for the ViewController and storyboard file for the view.
An AboutBox based component file structure looks like this
Why? With this structure, the development will have many advantages:
1- Staff exchange: Developers in the team will easy exchange or share the work. One is not available, other can just take over.
2- No staff dependency: The code and development are transparent to the team member. Everyone knows and can help others.
3- Time and cost saving: There wont be any delay with long learning curve for changing and training staff.
4- Standard coding style: The codes to access the components are in the root module. Coder will use the same function to call the component. No new code, no new bugs.
Look at the sample code for components in Github. The AboutBox is to show file structure and simplest call without param passing and return. The getPin is to show the use of protocol and delegate to return data. They are straight forward and simple to share across the team.
…
