Do the right way with Component
IOS Component based development in “defined” level
Can you release high quality major project in 3 months?
Humphrey in his book Managing the Software Process 1989 expressed the maturity level of software development. https://en.wikipedia.org/wiki/Capability_Maturity_Model
“ the levels are defined as:
Initial: The software process is characterized as ad hoc, and occasionally even chaotic…
Repeatable: The necessary process discipline is in place to repeat earlier successes on projects with similar applications…
Defined: The software process for both management and engineering (development) activities is documented, standardized and integrated into a common software process set for the organization…
Managed: Detailed measures of the software process and product quality are collected. …
Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies,...”
Man! English guy has the way to make thing so ambiguous. Put it in very simple way: If a coder writes the code from A to Z for the app, then it is “initial” level. If he then did a lot of code libraries, and re-use them instead of re-write them, then he is in “Repeatable” level. You can take the MS studio, Xcode IDE, and Android Studio are in this level, as most of the components are integrated from within the IDE. Many classes are pre-defined and coders just use them, repeat the same steps to use them, not to re-write them.
The difference from the previous level is the re-useable classes, which are well tested. Therefore no need to re-code them anymore. The application is built faster, fewer bug in this level.
When people talk about the application by “defining” the components that form the application, then it is “defined” level. The work is done at the components level; bugs are localized and development time is short. We will focus only the “defined” level and its corespondent development.
At defined level, the development key is not to develop the application, but to develop the components that form the application.
Component vs component
Since it is rather confusing between interactive or plug in component in IDE and blackbox or base component in development, it is better to make it with examples.
Say in Xcode, you can drop a TableView into your ViewController. The TableView is reusable component of the Xcode IDE. You can use it in virtual environment or programmable. This is a typical interactive component, not a blackbox component.
Why? because it is not self complete. It is used to carry data. Without the coding and data from the controller part. It is blank. Also, at later stage, you can see clearer that a tableview can not be used to “define” a system. It is only a integrative component.
Define an application
Lets practice a ”define” on an application. What are the components required to form a Spotify or a Tumbler?
We will need
1- A landing screen. It can have a videoplayer part, login and register buttons. We can change the video and reuse this component in other application, yes? yes!
2- A login screen. It must have username and password. This can be used in other apps, yes? ok, it is another component.
3- A register screen. It has email, password and submit button. Yes?
4- A reset password, yes?
5- A profile screen. It is sure a component.
7- An About box? yes, it is.
8- A card form to list the posts from the others and yourself?
9- A post form for user to post?
10- …
You can see the based components yet? They form the app. They “define” the app. They work like the Lego. Putting the lego pieces together to form a structure. The lego structure is “defined” by the lego components.
This maturity approach practically saves people huge time and money. Have you ever seen three developers doing 3 separate login screens for 3 applications that login to the same server? What they did is the “initial” stage, which is understandable in the 90th, when we still work with Win95 and the dinosaurs were running in the park.
Stone age?
What? I am serious. Not kidding, even it is in 2018, I saw they code from A to Z for the apps. I am assure you. Now, even in this century, there are many software companies with popular products are still in stone age for their software development. They did the right thing with their products but they did them in the wrong way. Oh, you can guess. They spent huge money and time to … debug and finally re-do the whole application over and over again… still in wrong way!.
You can see what my team and I can do in 3 months, they do in 2 years. It is still not the end of it. After those 2 years, they get 3rd party to do a new one for another 12 months, then they not happy, get another new development for another 2 years. Man! I have seen this sad story many times in many places. They keep doing thing in the wrong way!
How could it happen? It is the maturity of the development environment. The project owner has no glue of the software development maturity. The coders — not software engineers- only know to code. They keep doing wrong way over and over again. Costs a lot of time and money. Think about someone stays 10 years old for … 30 years!.
Component development
Again, my team and I have done many major projects in average 3 months each.
How? the component based development is the key. We developed many blackbox components: login, register, reset, profile, setting, PIN, barcode reader, QR code reader, VR model, posting, sharing, table based listing, card based listing, pay-getway, RFC component, sockets realtime, Rest components… on both client and server sides. Some components we did a few for the choices. The idea is my team built the new apps by reusing the components. We coded only 5–10% max of the app. We do major applications in 3 months average.
You will find later in this series some tutor for components that to present the idea of development based component. Not to develop the application, but to develop the components that form the application. It is the difference.
The main project is empty cell
The application by itself will be more or less an empty cell. It looks like this
The components are the sub projects, that form the main project or application.
Sub-project component
Why we say sub-project? because the component itself is another empty cell for it child projects those form this bigger size sub-project. It looks like this
Can we do a few sample sub-project components that you can refer to? sure. You will see the GitHub for the demo of the component. The AboutBox is to show file structure and simplest call without param passing and return. The getPin is to show the use of delegate to send data to parent. They are straight forward and simple.
Child project component
The idea for the child project component is an simple UI screen with a single button, that to call the component. It acts like a demo, to bring up the component as a blackbox module. The module or blackbox component can be in any language, and any UI form, as long as they serve the purpose of a complete functional module. The structure is like this
You might see by now the development for this level is not for the application project anymore. It is the development of the child components that form the based components, that in turn form the application.
Since the components are independents to the application. They are reusable for many applications those in the definition require them.
As referred to “Do the right way with Storyboard” article, the component will has its own folder, storyboard, controller and extension. For examples, under the folder GetPinViewController, there would be
1- GetPinViewController.swift for the class model and control.
2- GetPinViewController.storyboard for the class UI or view.
3- GetPinViewControllerTableExt.swift // for the table delegate if using tableView.
To plug this component into the parent project, you drag and drop the GetPinViewController folder into the parent project in Xcode. Dont copy it. The correct setting is like this
Why? the GetPinViewController component is belonging to the child project GetPinViewController. The development of this component is for this project only. The parent project is only use it as using a blackbox. Therefore, if you made copy, then you would have shifted the ownership and broken the blackbox development circle. We have discussed this issue in previous article “Do the right way with Swift”.
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
In Xcode it looks like this
In main.storyboard of the component project, it looks like this
The simple version to call the AboutViewController is like this
func loadViewControllers(_ named: String) {
let storyboard = UIStoryboard.init(name: named, bundle: nil)
let targetViewController = storyboard.instantiateViewController(withIdentifier: named ) self.navigationController?.pushViewController(targetViewController, animated: true)
}
The code bind the button Click action looks like this
@IBAction func btnClk(_ sender: Any) {
loadViewControllers(“AboutViewController”) }
Note that the AboutViewController has it own storyboard, not in main.storyboard and linked with a segue. We use this structure always for all component projects.
Why? With this structure, the development will have many advantages:
1- Staff exchange: Developers in the team will easy exchange or share to 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 code 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.
5- Team work enable: You can do team work with mobile app via component development. We have discussed about it in “Do the right way with Teamwork”.
Using Plugin
Most people do the child components from scratch. Some use plug in. Often, the plug in approach is faster, but need more resource for testing before putting in production. We will try to do a tutor on plug in approach shortly. Lets try this link, when it is enable.
…
