Tallan: A Mobile Experience

As part of my first series of posts about my experiences at Tallan, I'll be going over some of the first projects that I ever did after completing training, and how they shaped my development perspective.

At Tallan we do everything, and that is one of the appeals that I had going into working with the company. I thought that the amount of exposure to different technologies would allow me to try out different things, and boy did I do that. During training one of the things they mentioned was that they suggested we join a "Practice" so that we can further develop our skills in a certain area that we could master as a way to focus ourselves in the field in addition to our regular duties. The "practice" that stuck out to me the most was the "Mobile Practice" as the director, Matt Kruczek (who became my mentor), sold us on the idea of building consumer facing products that really sounded with me at the time.

And so I was able to join the exclusive club of being a member of the elite Mobile Practice, which has been the driving factor of my Tallan experience.

My First Project (Tass iOS)

The Task

The project was to rewrite the existing Tallan Internal Time and Expense Entry iOS mobile application from Objective-C to Swift.

The Challenges

  • The original developer was no longer with the company, and any form of documentation he had was not available.
  • The senior overseeing my work didn't have much experience with Swift at the time, while I didn't know either language, the framework, or the processes with Apple.
  • There was no documentation for the usage of the web services, and it was built in java code which had been built and largely untouched in ten years.
  • One request that my director asked was to refactor the data layer portion of the application to use the service/repository pattern, so it was not a one-to-one conversion.

The Approach

  1. The first thing I had to do was to understand what I was building, so in order to learn that I drew pictures of each screen into my notebook and then drew lines for different behaviors that I saw - such as what did the element do, where did it take me, and what it's purpose was.
  2. Once I had an understanding of the thing I needed to build, I started to work on the UI portion for each screen, working my way from the login screen to the time and expense entry screens. Making the necessary static connections between the screens so that I could get the flow down.
  3. Then I started to hook up various web services, using what I could gather from the existing code and integrating it with the service/repository pattern that I was tasked with designing. After a bunch of research I came back with a callback design that enabled me to propagate the behavioral patterns I needed to accomplish on the front end.
  4. Connecting the UI and the data layer came next.
  5. Finishing off the development was some cleanup tasks such as validation, some UI threading issues, and some UI adjustments.
  6. Next we were ready for alpha release, to which I had to research a bunch about how and where we would be able to deploy this app, which I later found out to be through an enterprise app.
  7. We received some quick feedback, mostly around some validation, missing business rules, and UX enhancements, but everything was working for the most part. There was an image transfer bug that intermittently occurred during some uploads that we were unable to pin down.

What I Learned

  • I learned a crap ton about iOS, Objective-C, and Swift. I had built an application from start to finish and deployed it all in one go.
  • I learned about the service/repository pattern which would guide a lot of my future designs.
  • I learned how to elicit feedback directly from my clients and work to satisfy them.
  • I learned how to step out of my comfort zone in terms of what I knew, and to research best practices and design patterns to fit my needs.
  • I learned to be a self-starter - how to create a process plan for completing a project, and to manage my own tasks.

How Can I Improve

  • Test Driven Conversion - One of the problems that I faced was that I had missed some of the business requirements during my conversion. One way around this would be to start with a test driven conversion, where I could write tests against the original code first, and then apply those tests to my new code.
  • Component-by-Component Conversion - I didn't know what you can actual intermingle Objective-C and swift in the same project. Knowing that I would have took the original project and screen by screen start replacing the necessary classes with their swift counterparts. This would have decreased the amount of variance between the existing code and my code.

Comments

Post a Comment

Popular posts from this blog

Uncle Bob's Clean Architecture

Image
The basis of my current understanding of architecture comes from the brilliant mind of Robert C. Martin (Uncle Bob). You can find the original post through his blog , which I strongly encourage you to read. In this post I'll try to summarize some of the key points I've understood from his post. Clean Architecture Source Clean architecture is a design used to emphasize the structure and relation of your various code components to promote the idea of Dependency Rule , such that "source code dependencies only point inwards" . Clean architecture is able to promote this by defining that your software system consists of various layers , that can be organized in such a way that the layers point in one direction, and a dependency graph will not have circular reference. The reason this is important is because it allows you to keep closely code related, and increase clarity of how components fit into your system. Explaining the Layers We can really separate out this
Read more

C4 Model: Describing Software Architecture

Image
The point behind a presentation of Visualizing Software Architecture , by Simon Brown, was that we need to standardize the way software developers communicate with each other in respect to our discussions of software architecture. As part of Simon's consultation, one exercise he gave to software architects was a simple task to white board the architecture of a software system. The results he received varied immensely, and there was never a defacto standard format that he received from this exercise. When inspecting the feedback from the participants, the general answer was that it was easy to come up with the design, but difficult to properly put their ideas onto paper, or white board in this case. White Board Example, c4model.com Simon sought to start a movement by defining a set of organizational rules to help us describe our software architecture with a set of standard terminologies. His work has let to C4 Model , which stands for C ontext, C ontainers, C omponents,
Read more

Multi-Tenant Design: The Basics

Image
As your software system begins to grow and become a successful, you may find yourself at a place where you will want to monetize your software by allowing other companies to use it. One such design that will come in handy is called the Multi-Tenant design, and it allows you to license your software to other companies, allowing them to use your software system for through some contract. You manage the system, and they are merely an entity within it, a tenant. Source At its core, a multi-tenant design is driven by the idea that each tenant contains an identifier, which is then passed through with each request or action. By including this information, the system will know what behavior or data set to pull from. Traditionally the tenant identifier is GUID  that is transferred through HTTP requests as a HTTP header, x-tenant-id . The value is then kept within the thread context, and used to determine the configuration of a request, as well as the data it can access. Data should ei
Read more