I had finally received the call that I was looking forward to for a long time. I was going to be an iOS Mobile Device Specialist! You are probably wondering what that is, especially since this is an iOS development blog and word "developer" does not exist in the job title!
Well that was perfectly fine with me, because if you read the first introductory blog post called "Soaking up iOS Dev at JMU" you would be able to guess my position on finding a developer job pretty easily by now. Deep down I just knew that I was not quite prepared to be a full time developer or even land a full time developer job. I do not usually promote those types of cynical thoughts, although for me it was the best decision to make at the time. The iOS Mobile Device Specialist position had the potential to provide many opportunities that I was really excited about. I would be able to work with two people that are my mentors and now great friends, who prior to this job had a combined 15+ years of experience at Apple. These two continue to play a impactful role in my professional and self development journey to this day.
One of the guys had created a master plan for our impact in the mobility space and we were more than excited and ready to take on the challenge. Throughout the journey, there were so many educational, career, and self improvement opportunities available to be involved with. I could just tell that I was right where I needed to be. Also, the fact that I would get paid to learn how to support and manage thousands of iPads was pretty awesome! Of course, there were potential iOS development opportunities as well, one of those being that I was introduced to a life changing software development tool called FileMaker, but we will come back to that a little later! There was just one other thing, there would be a decent amount of labor intensive work that went with the job role. But, like I had experienced at my previous internship, I knew that certain things had to be done in order for me to get where I wanted to be. For me, I would be fine doing other jobs outside the role of an iOS developer so that I could potentially find my way into that role or just anything that involved iOS apps!
Now it would be pretty boring to hear about everything I experienced during my first few months getting comfortable as an iOS Mobile Device Specialist, but there was definitely a lot of work to do. At this point, it was important that I understood the job responsibilities and experienced the "grunt" work that went along with them. This would allow for process improvement further down the line by gaining an understanding of how everything was being done at that time. To keep it simple, just one of the responsibilities consisted of managing inventory and a break/fix queue for thousands of customers and iPads. This type of project would be the first of many detail oriented projects that I would be involved with at the company. It helped me to learn how to use different asset management systems and allowed me to understand the importance of data organization and integrity. The iPads would later play a huge role with the call center team and troubleshooting with our customer. If something was incorrect in our iPad deployment process, there would be many issues further down the line that would effect other departments and systems. It was pretty exciting to know that I did play a small role in the company and that these types of experiences could potentially evolve into iOS development opportunities!
The senior mobile device specialist was the reason why I had chosen to accept the job and he was a huge driving factor in bringing me onboard. We had an instant mutual understanding for what needed to be done and that was "all she wrote". The guy is just always exciting to be around and is not only a brilliant mind in the iOS mobility space but in many other innovative technology spaces as well. He believed that I had the ability to help the team by developing apps to improve old processes. No one at the company before had accomplished developing an iOS app and I was both excited and nervous for the challenge. His belief in me to succeed alone was very impactful. He is a mobility visionary, someone who is able to think of innovative solutions to solve problems, but also someone who can create a plan for how our mobility team can change the way our leadership thinks about mobility and also how our customers gain more value by using their iPads. I encourage all of you to find someone who is just as excited and passionate to learn as he is. Those who help you with professional and self development are invaluable and can also turn out to be life-long friends. He is just a top notch guy, mentor and life-long friend.
To bring his forward thinking plan into action, we would need to create a MCOE or Mobility Center of Excellence. Explaining an MCOE is a topic worthy for an entirely separate blog post, but essentially we needed to find a way to create the best mobility experience as possible for our customers using iPads so that they could feel more helpful in their job roles. This would provide more valuable experiences for their customers which would eventually generate more revenue for the company. For us, this meant that a lot of things needed to change for us to even have time to focus on creating an MCOE. This would not only present more difficult challenges but as well as some opportunities for us in the future.
In order to create the best experience possible, we really had to understand more than the just the mobility aspect of the job. Those other areas of understanding are networking, asset management, systems, operations, process improvement, how to get things accomplished through relationships and more. Aside from these areas of understanding, configuring and deploying thousands of iOS devices to our customers, we also had to manage a lot of other projects that dealt with asset management. Along with those responsibilities, there were a few pre-existing challenges surrounding these assets. As you can imagine with only a few individuals available to manage the data in regards to our assets, we had to be efficient. This is where the vision of our senior mobile device manager came in. In order to be better utilized in our job roles so that we could develop an MCOE, we needed to find a better way to manage our assets. As you can imagine, with only a few people supporting thousands of iPads as well as having other a lot of other responsibilities, solving the asset management problem was also a big part in achieving our goal of creating an MCOE.
You now have an understanding for how important it was for us to find or create a helpful tool that would help us to efficiently manage our asset management processes. Luckily my two co-workers had previously been briefed about an Apple owned company called FileMaker Inc, who provides an affordable, flexible and reliable tool called FileMaker. It is a relational database application which integrates a database engine with a GUI, that allows users to modify the database and drag new elements into layouts to create custom apps. FileMaker helps developers to quickly create powerful custom apps capable of scaling in the enterprise. For me, the huge benefit with FileMaker is that is a script based, low code no code development environment which did not require learning, memorizing or staying up to date with with rapidly changing languages. FileMaker's platform was just the paradigm shift in programming that I needed. iOS apps could be created in a significantly less amount of time with less frustration and just as many features. The only downside about FileMaker is that there are less native iOS features to make available to the user. After reading about improvements that FileMaker had made over the years, I knew that the company would eventually evolve FileMaker to provide a more native iOS experience for the user. Now up to FileMaker 17, they have introduced layout transitions, iBeacon support, and local push notifications. I would love to see press and hold or swipe to delete actions! Although less native and elegant than Apple's Swift and Xcode, FileMaker is a very helpful tool for developers to quickly create powerful iOS mobile apps for the iPhone and iPad. With the challenges to solve and the newly introduced FileMaker development tool at hand, I was so excited to get started.
It did not take very long to get up to speed with the FileMaker environment as I was using the suggested "Get Started" documentation, asked tons of questions to the FileMaker Community and spent some time reviewing the starter solutions that FileMaker provided. This is where this blog clearly gets more valuable as we can provide recommended recourses for others who find themselves looking to use FileMaker for developing apps. In our situation, we started out with FileMaker 15 Pro Advanced and FileMaker Server 15. This would allow us to host our apps over a network so that we could use the app anywhere in the building. FileMaker also allows you to host your app locally so you can host an to check your development changes on an iPhone or iPad. There is so much more information to cover, but we will just get started by introducing FileMaker! The best way is to just dig in and get involved! Check out some of the resources below!
Getting started with FileMaker resources:
After the short amount spent time getting used to FileMaker, I was ready to take on our asset management challenge. We needed to use FileMaker to update data in a database. Our iPads had tags on them with a barcode and numbers. We wanted to be able to update data related to each iPads by scanning each barcode into a FileMaker database. From there, the user would be able to make their changes and submit them to the database to update. For a self taught developer like myself, this was going to be difficult. I knew that I had been hired for this challenge and I believed in myself enough to get the job done. Although I was a bit nervous, I was even more excited to have my hands on my own iOS app development project!
The project was to develop an intuitive iOS app used with FileMaker Go on an iPod Touch. The reason for selecting the iPod was because it was the only device able to integrate with a barcode scanner that would scan multiple asset tag barcodes at once. For those of you who are learning and developing with FileMaker, the asset tag numbers scanned from each barcode were then sent to a Number Type field called "Asset Tag" on the body part of the List View FileMaker layout. That was a mouthful, but if you break it down into pieces, it is much easier to understand. We will be developing tutorials in the future that go over the development of this project when our readers express interest. The barcode scanner is called a Linea Pro scanner that integrates to the iPod through the iOS Keyboard settings and the Linea Pro ScanBoard App. The scanner also fits into the lightening port of the iPod which then charges the iPod if it has low battery. Once the data is sent to the "Asset Tag" field, we utilize a very helpful feature that FileMaker calls "Conditional Formatting". This allows developers to change layout objects based on calculations and values. Conditional formatting changes the way an object is displayed, such as changing background colors, text formatting, and other design changes. So, when the asset tag number is placed in the "Asset Tag" field, our scanner is triggered to automatically return to the next field, so we run an OnObjectExit script trigger that checks to see if the asset tag number has an entry in the system or not. If there is an entry, we set a variable to a particular value such as "Yes". If there is no entry we set the variable to the value "No". Then, our conditional formatting calculation on the "Asset Tag" field is set up to check if the variable contains the value, "Yes" or "No". If yes, the conditional formatting feature is set to change the background color of the "Asset Tag" field to green. If "No" the field is set to change to red. This lets the user immediately know if the asset needs to be added to the system or not. Finally, there is an information button that would query the database to get the latest asset information such as location and model type. Although it may seem like we have covered a lot just in this one paragraph, these development tasks are rather simple in FileMaker. As we mentioned, it will be much easier to visually see in our future Youtube tutorials when our readers express interest.
We have just covered a small portion of our iOS development journey and reviewed some intimate development details that others may not choose to include. This is the one of the most important projects that continues to provide value to many people that will help us to develop an MCOE. We will stay on the topic of our iOS asset management app in the next blog as we review further into what it took to have our first small impact on the organization in regards to developing an intuitive app, finding the most efficient way to update asset data in bulk, and using my FileMaker knowledge outside of my 9-5 to start making money.
Coming up next: Year 3: 2016 - Developing an intuitive, efficient and powerful iOS app experience