SmallSharpTools

My name is Brennan Stehling. Find me on GitHub.

[smallsharptools-blog]

Better Debugging for iOS

There’s a lot of tools out there from Facebook and some hidden gems which more iOS developers should get to know. Below is a list.

If you are not leveraging the LLDB debugger more now is the time to start. I configured mine with .lldbinit (see below) a while back and having Foundation and UIKit loaded automatically as well as Reveal has been a huge time saver. I created a symbolic breakpoint on UIApplicationMain and added the configured commands for foundation and uikit to load those frameworks. I also have it load Reveal so that for any app that I run in the iOS Simulator I can jump to Reveal and load the view hierarchy. And now with the new 1.6 release of Reveal I can even save a snapshot of an app to use later for comparison or to pass to a co-worker to show how a layout is assembled or debug a problem. To get even more out of LLDB I am now using Chisel from Facebook. It adds several commands that you can use during a debug session. One example is the pvc command. It prints the view controller stack from the current view controller. When I work with an app I do not know well it is sometimes hard to know how the app is assembled so I like to set a symbolic breakpoint on viewDidLoad and then I have to try to figure out show how the view hierarchy is put together. Now I simply run pvc and it shows me what I need to know. This is just one of several helpful commands. There are many more tools which Facebook has published as Open Source.

ComponentKit

AsyncDisplayKit

Pop

Infer

Now that I have started to using Chisel the next one I plan trying is Infer. And if I do feel like hacking the UI a bit I will get into the other three.

.lldbinit

.lldbinit

[smallsharptools-blog]

Working with Xcode Developer Tools

I used a great tool called Asset Catalog Creator to make sure I had all of the necessary App Icons and still the validation process chokes on the new build. I find via Stackoverflow that the CarPlay icon can be removed to get validation to pass. After I found that post on Stackoverflow and removed the CarPlay icon I tried to validate the newly created archive and it timed out multiple times. Finally validation did complete successfully. This is just an example of all the time delays which are involved with iOS development which do not even include writing code. When the tools let you down there's not much you can do. Apple has a lot of bugs to fix. Let's hope they delay any new features until what they have released is stabilized.

[smallsharptools-blog]

Drawing Rounded Corners

It is often helpful to draw images with code to cut down on image management and also make your images adapt as needed. I just published a project on GitHub which shows how drawing a few useful shapes is done with iOS using Core Graphics.

I wrote up the details in the README to complement the comments in the code to help illustrate how it works. It may be confusing to start but once you understand what each Core Graphics function is doing you'll realize it is quite easy. With the iPhone 6 now requiring PNG images to be 3 times higher resolution than the original iPhone it is important to adapt to support the higher density screens so your app does not look grainy or blurry. Drawing your icons and shapes in your app will help you cut down on using PNG images and allow drawings to work no matter what the resolution of the new screen. [ Drawing Rounded Corners ]

[smallsharptools-blog]

Innovating Slowly

It is important to evolve a widely used product slowly so you do not confuse and frustrate your customers/users. We've seen for years how Windows lurches forward with a great released followed by another which looks promising at first because of the skilled marketing around it but soon fails due to actual users using the new release. Windows 8 is apparently one of the flops. Microsoft was rushing to get into the tablet and touch screen game and was aggressive about it. They did not account for the fact that pretty much every user had a computer without a touch screen. I have owned Macs and Windows computers for years and when Windows 8 came out my computer was fairly new yet it did not have a touch screen and the track pad was about the width of two quarters. There is no way I could use it for gestures. In contrast, my MacBook at the time had a trackpad bigger than an iPod touch before gestures were mainstream and I was able to use gestures with it without any trouble. Apple knew what was in their pipeline and ensured that the hardware they were rolling out would support future UI updates. You can see even now how Apple is seeding the market. Last year the iPhone 5s included the Touch ID interface which is now an important part of Apple Pay. Millions of users already have this hardware and are familiar with it. It does not include an NFC chip but will allow users to make purchases in apps which leverage Apple Pay. Having all of the necessary pieces in place ahead of time helps to ensure success. Apple has also been slowly rolling out SDKs for gaming such as SpriteKit and the game controller SDK. Apple has something coming within the next couple of years. By rolling it out slowly it also gives developers time to learn how to leverage the new features so they are ready to go full speed when additional features and products are released. You've likely heard the criticism that Apple does not innovate. But how often are you disappointed by OS X like you have been with Windows over the past 10 years? Every update is an incremental improvement which improves the overall system while Windows is often a big jump forward often making changes that damage the user experience and convince CIOs to skips versions completely. Remember when companies chose to stick with WinXP and skip Vista? I've never heard of anyone opting to skip an OS X version. I have heard complaints about OS X and iOS changes but pretty soon people adapt and typically they learn to like the changes. Breadcrumbs I think of it as leaving breadcrumbs for users. You have a vision for where you want to users to be but know it is too much of a jump to bring all of the users along so you make incremental changes over time and allow your users to keep up and adapt at a more reasonable pace. In a way it allows you to be more aggressive with design concepts because you can train your users and lead them where you want to go. A great way that Apple helped everyone get ready for the iPod touch and iPhone was all of the commercials. Before the iPod touch and iPhone people had never used a touch UI before with all of those gestures. In every commercial the iPhone was in the center of the screen with hands interacting with the interface with various apps showing everyone how to use the new touch UI. The commercials were effectively training videos. Once people finally got their hands on their first iPhone they knew what to do with it. It was smart and effective and it took time to train everyone about the new touch UI. Remember Wave? There are many examples of new released going too far. Google Buzz and Wave failed largely because they did not slowly bring users along with them. Wave was great but many users just did not understand it. More education in advance of releasing Wave could have gone a long way. Perhaps Google could have incorporated some of the UI features in other products like Docs gradually. Wave was great but for mainstream users it was too much of a stretch. For Google engineers it was obvious because it was common to them. There needed to be a bridge between their experiences to help mainstream users to acclimate to the modern concepts of Wave. And unfortunately Google shut down Wave before users could figure it out. If they had moved a little more slowly it could have worked out and we all would be happily using Wave today. Facebook occasionally goes too fast and has to help users catch up. Where Facebook has an advantage is frequent contact with users around a single very popular product. Users often don't like changes but eventually give in and accept the changes because the frequent use helps them acclimate quickly. Right now with Messenger it appears that Facebook is having to educate users on the benefits of a secondary app on the iPhone which is asking for permissions users do not understand with blog posts making them even more paranoid. Now their efforts to educate their users are happening after the fact which is much harder to do. Slow and steady seems to be a good way to go once you've got an established product. On the way there you can take more risks, but at some point you need to stabilize and adjust your speed or risk losing users who are just not going to make the jump with you.

Photo Credit

[smallsharptools-blog]

Automatic Build Numbers and Xcode 6

It is time again to get familiar with a new version of Xcode and a revised build process. This time iTunes Connect includes a change which has caused many developers, including myself, to get blocked from deploying a build to the App Store for review. The problem was that I uploaded a build which I had to replace but since I have been making the build number the same as the version number. Now iTunes Connection requires the build number to be unique with each upload. Once I learned this I started to update the build with each push with a timestamp value which would be useful because I would know when that build was created but I was not sure how to go about updating the build number automatically. Then I learned from iOS Dev Weekly that Jared Sinclair post a solution on his blog. His solution uses Git to create a count of the words from the revision list command which ensures it is unique. It also incorporates the branch name while using the Debug configuration. It is an easy script to paste into your build target as a script which runs with the build. As Sinclair explains it modifies the .plist in the output folder leaving your working files managed by Git unchanged. I prefer to use a timestamps which works well for me and helps me with seeing when builds uploading to iTunes Connect were prepared. Automatically updating the build number

You could even modify it further to concatenate the username or even the Git branch if you like by combining Sinclair's solution with this timestamp alternative. Either way it will help you with pushing builds to iTunes Connect. You can see from the attached screenshot that I changed the build number a few times and finally settled on a dot delimited timestamp which will be easier to read.

[smallsharptools-blog]

Why do we need a new payment system?

It appears people do not understand why our current credit card purchasing process is flawed. Just look at the breaches at Target and Home Depot. Those breaches won't be possible with Apple Pay which is simply a layer of branding over a standard for purchases which started in Europe and is slowing being adopted in the US.

Here's why it is much more secure. When you make a purchase now you provide your card number by swiping it. That number is then used for that purchase and could be used to make additional charges after you've left. You provide the same number with every single vendor. You have to trust that all of them won't be breached and banks have to invest heavily in fraud protection in case cards are compromised which translates into higher fees. I recently had my card locked and was told it was due to a vendor breach. I have been to Home Depot recently so I expect I am one of the lucky ones. That was more than a little inconvenient to have to go get a new card. With the new system instead of sending over the same number every time a unique token is created for each purchase which can only be used once. Nothing can be done to take money from your account if it is compromised. Of course you will always be able to fall back to using your card, like if your phone battery dies, but most of the time you will be able to use your phone to make purchases.

There's another way Apple Pay solves a problem. It is currently inconvenient to make purchases with mobile apps. With each app you must enter your card details. Then your card number is either stored on your phone or on the servers for that vendor and in both cases your card details could be compromised. It happens all the time. If you use Apple Pay with apps for Amazon, Eventbrite and Walgreens you will be able to easily make a purchase without entering your card for each app. Every purchase will be secure and your bank won't have to work that much harder to protect against fraud for those purchases.

It seems Neil Irwin over at the NYT times does not think the current system is a problem. Don't be like Neil.

Photo Credit

[smallsharptools-blog]

Migrating to iOS 8 and API Compatibility

Soon iOS 8 will be widely available and users will start updating their iPhones. Many will also be upgrading to the new iPhone 6 which will come with iOS 8. Now developers will ask themselves when to move to iOS 8 and drop support for iOS 7. I was just writing an email to my team to explain the timeline and how we will make this decision and I decided it would be helpful to share on this blog. Since most mobile apps work with an API there should be a concern for dropping iOS 7 support for concerns explained below.

Here is the general timeline.

iOS 8 is released later this month

Supported iPhones go back as far at iPhone 4S

Within 6 months the install rate for iOS 8 should be well over 80%

At 6 months we could move exclusively to iOS 8 and drop 7

The last build in the App Store which supported 7 will still be available to iOS 7 users

What this means is the last iOS 7 build should be quite stable since those users won't get any further updates. It also means that they will be locked into the API at that point. Further changes to the API from that point must be stable for as long as we expect the iOS 7 apps to be in use. The app could have a time bomb in the last release with a warning period, such as a 6 month window from the last release. Another option is to have a simple API call which returns a date to indicate when support for that version is OS expires. That way the API can change the date after last iOS 7 release is published in the App Store. In the final 2 weeks the app could warn the user that it will no longer function after that expiration date.

The advantage of moving to iOS 8 in 6 months is leveraging all of the new features without the overhead of maintaining backward compatibility for iOS 7.

Of course we could extend support for iOS 7 even longer if the cost of backward compatibility is very low. The jump from 6 to 7 was severe so the cost was much higher. The jump from 7 to 8 is not as severe. So instead of dropping support for iOS 7 in 6 months we could go much longer.

A key metric will be the number of iPhone 4 users which may start falling off once the iPhone 6 has been out a while. Analytics will inform that decision. Many will buy the new phone and hand their current iPhone down which is pretty common. The 2nd hand owners of older iPhones may represent many of today's iPhone 4 users and they will likely be using iPhone 4S and iPhone 5 devices within 6 months. Once well over 90% of the user base is using an iPhone 4S or newer phone which supports iOS 8 we can more easily drop support for iOS 7 and leverage the new features as much as possible. I expect within 3 months of the iOS 8.0 release we will see the iOS 8.1 release which is a milestone which gets many people to finally make the jump to the next major version. Once we see those users break from iOS 7 it will be a good indicator when support for 7 can end.

Photo Credit

[smallsharptools-blog]

These Are Not The Hackathons You're Looking For

Beware of the Hackathon which is not a Hackathon. Often when developers are recruited to attend a weekend Hackathon it is presented as a learning opportunity and a chance to network. I've attended many Hackathons and I have learned a lot and have met many great people. I have also seen people participate with the wrong idea of what a Hackathon is. Here's a clear example of a non-Hackathon.

First, it is not an opportunity to get a team of developers to do free work for you which allows you to take ownership of all IP created during the Hackathon. Second, you cannot control what is created during the Hackathon in order to meet your needs to develop a product for your company. If you are looking to attend a Hackathon with these ideas in mind I will tell you right now, you are not welcome at that Hackathon, or any Hackathon. If you try to exploit developers at a Hackathon it will quickly become apparent and these developers will talk and it will reflect badly on your reputation going forward. If you want to get some work done, by all means go to the Hackathon, participate on one of the teams and help build what the team chooses to build. While you are participating it is a great opportunity to scout for talent. After the event you will have new contacts you can reach to hire for contract work or even a full-time position. A Hackathon is an ideal event to do scouting. Where else will you find developers passionate about their work who are so eager to build something that they give up their whole weekend?

A Hackathon is about trying out ideas and seeing what works and what makes sense. It is also about experimentation and trying something you would not normally try with your day job. Sometimes this experimental work can become something you apply to your day job, but that is not the only goal. What you will certainly apply to your work going forward is the experience you get from participating on a team at a Hackathon.

What Should I Expect At A Hackathon?

You should go into a Hackathon excited to learn and meet people. There should be guidelines for the Hackathon which also should be vague enough that you can get creative with whatever you decide to build with your team. It may have a focus on mobile or commerce or perhaps even travel with prizes for teams which create something which meets the criteria in a specific category. By all means go for the prizes which may be cool hardware or even a lot of cash. Food, drinks and prizes will get lots of people to show up. Now take that opportunity to form a team and build something cool and ideally something you and your team will use once it is built. Do it for yourself and your community. You can either pitch your own idea or join a team to work on any idea you find appealing. You should not be given a list of features for an app which you work on overnight with no sleep to then hand over all IP rights to someone else. That's not a Hackathon. That would be contract work and you should be paid for it. And if you do contract work on a rushed schedule you should be paid a premium for it. But make sure there is a clear divide between a fun Hackathon project and paid contract work. Make sure you know where the line is drawn as your going into it. There are times where this line can be blurred, and if it is, make sure everyone is clear about it going into it.

How Should I Work With My Team?

After multiple Hackathons I have worked in multiple ways. Perhaps the best way to work is to immediately make everything Open Source on GitHub with a new Organization. Then tell everyone about it so they can even join in remotely if they like. From there you can add everyone on the team with admin access and start creating repositories as necessary to get the work done. Setting a permissive license on all of the code like the MIT license will make expectations and IP rights clear. You can still eventually make a company of it, but while you are at the Hackathon it should be clear that you are working as a team. Keep in mind that companies like Automattic (WordPress) and Netflix are companies which run on software they have released as Open Source. Releasing your work during the Hackathon does not mean it cannot become a big successful business.

What Should I Avoid?

If you get to a Hackathon and someone pitches an existing product and a new feature for that product, stay away. You are not going to get any credit or equity. This person is looking for free work at the Hackathon because they are not willing to pay developers to do the work. Why would they give you any compensation? Instead, choose to work on something that is seriously stupid. The Design Lead at Spotify makes a great case for why side projects, such as projects done at Hackathons, should be stupid. Can I Do A Non-Hackathon? There are events where ideas are formed and pitched but nothing is built and people do not work all weekend toward preparing something to present. If it is about generating ideas and not writing any code then simply do not call it a Hackathon. Come up with another name. And if you need to put a lot of legal verbiage all over the event description and claim ownership of all IP creating during the event then maybe you should consider not doing the event. Or maybe make it a private event and invite specific people to participate with the terms clearly defined. If it is an open event the teams should be free to take their ideas and do what they like with them without any limitation after the event. If you are not paying them for the ideas and their work then you cannot claim any ownership over the IP.

What About Work Hackathons? There are frequent Hackathons at companies like Facebook. The "like" feature was created during one of these Hackathons. This is where the line between a fun, personal project without pay crosses the line with real work. If you understand it going into it then that is alright. Be sure you know what you are getting into from the start. The great benefit of these work Hackathons is you can try things you normally would not get to try, use resources you otherwise could not access and work with people on other work teams you don't work with normally. You can accelerate your learning and get to know several people during these types of Hackathons. And your work may even become integrated into the company's products. You could even create a whole new product and your team could be asked to continue with that effort, but don't go into it with grandiose expectations. Just have fun and build something you will enjoy.

Still there are companies who will ask you to work over the weekend and call it a Hackathon. Here's a funny example. A Hackathon is something that should be voluntary and you should be not kill yourself to complete the project. I never work on projects overnight at a Hackathon anymore. That is no way to create something worthwhile or something you will want to continue working on later.

It may help to identify what you want to learn and who you'd like to meet. I attended a Hackathon a couple of months ago and wanted to build something with a specific technology and wanted to meet a few people with specific skills. I did just that and and we all had a good time and learned a lot. I also kept my eye on the developers on my team and the other teams. During the Hackathon I was scouting for new hires and found an Android developer with impressive activity on GitHub. Since then I have hired him and a classmate he recommended. The Hackathon was a great experience and look forward to attending the next one. (Please follow this blog on Tumblr)

Photo Credit

[smallsharptools-blog]

Backing Up With Glacier

For years I have been buying external hard drives and running backups with Apple's Time Machine software which has been terribly unreliable. Just recently my 1TB backup drive at home failed I believe due to failures with the OS X filesystem and not the hardware. I no longer trust Time Machine for backups so I have jumped to a solution I have been considering for a while. It is an app called Arq which stores everything on my own "vault" on AWS Glacier. The Mac app cost $39 and storage on Glacier is $0.01 per gigabyte per month. It is similar to Dropbox but will allow me to point Arq to local folders that I want synced with Glacier and will then cost very little. I could store thousands of photos and videos and still pay less than $10 per month. Since I have been paying between $100 and $200 per year for new hard drives, thumb drives and SD cards I think this solution which will not fail like my current system has already I think it is a great option. I can also store files on AWS S3 which costs more at about $0.03 per gigabyte per month if I want to access the files immediately. With Glacier it takes a few hours to get the files out of the storage system while S3 is built for be accessed quickly at any time. I am still using Dropbox for a limited number of files I want to have access to at any time while most of my work is it folders managed with GitHub. I am one stop close to being 100% working in the cloud. Thumbdrive Backup Another alternative to Time Machine which I have been using is a simple shell script to run rsync on my MacBook to copy files efficiently to a thumb drive. The script is shown below. You could adapt it easily to create your own backup system from your Mac to a thumbdrive. It has worked well and if I did not move to Arq and Glacier I would be doing this with a scheduled job on my Mac Mini at home, but I would still risk a hard drive failure. That was the deciding factor to finally move to the cloud. What Next?

I have a Mac Mini at home which I made remotely accessible while I work on my MacBook regularly. I'd like to have a way to efficiently sync important files to my Mac Mini when I am home which then syncs the important stuff which is not in Dropbox or GitHub to Glacier with Arq. These really should just be files I want to put into long term storage, like past client projects which I want to move from GitHub to free up my paid repos but not risk losing them if a drive fails. Perhaps with the Yosemite which includes clever location awareness features I can create a client which runs an agent which syncs files with my Mac only when I at home. I could see this also be useful for office workers who could automatically have their laptops sync up when they are in the office. Add that to the list of cool apps to build.

backup.sh

Photo Credit

[smallsharptools-blog]

Developers: Eat Your Veggies

Often it is irresistible to get to the good stuff. I mean the stuff that is really interesting on a project and delay ever working on the more unpleasant work as much as possible. I try to resist this urge and need to be better. It really comes down to a process which I can follow. Simply writing down a list of tasks which must be completed to finish my work has helped a lot. My desk is littered with sketches of ideas as I work out layout and coding issues alongside lists of crossed off items.

Breaking It Down

One of my college professors taught the importance of breaking a job down. This was for a business class and he used a real-world example of a hospital project which was getting a new wing. He was personal friends with the lead contractor and he explained how you have to dig out the space for the basement, pour it, get the plumbing and electrical in. It all has to happen on a timeline which is managed so the people and resources he would need would be in place when needed. If you put the walls in before you do the plumbing and electrical you will make the job harder and if you do not time it properly there will be delays.

In the same way, it may be necessary to set up a timeline for everything which needs to be ready when you are building out an app. Nearly every app has a backend with an API and those skills differ from the skills used to build the frontend so coordination may be necessary. When everything is broken down and the dependencies are understood you can attempt to coordinate efforts. This leads or a more predictable timeline and a allows the team to be as productive as possible.

Prototyping

Also in construction they often build a prototype to ensure the final build is built right. Building a prototype has multiple benefits. The builder can try out a new technique and train the team on this new technique before committing to the final build. It also allows for the designers and architects to see a real representation of their plan so they can make some adjustments if necessary. It also allows for feedback from everyday people.

With software an early prototype of just a few mock screens just to show the design and interactions can go a long way to learning a technique and iterating on ideas before building out the app.

Eat Your Veggies

Once you do break down a project and build out some fun prototypes you will be faced with what to do first when proceeding with building out the entire app. This is where I have to make myself eat the veggies instead of filling up on dessert. I do find that the "hard stuff" is much easier when I do break down the project. What is normally hard, like a complex layout and interaction, is made possible by building out a lightweight prototype. I can then take that knowledge and code and use it to build out the app.

My GitHub account has been holding area for ideas and prototypes like FullScreen, PhotoZoom and Playlist. I often refer back to these repos and extract old code to new repos in order to modernize and refactor the code before dropping it back into the app. I'm finding I like "eating my veggies" lately. When I knock out a difficult task which I have made small by breaking it down and isolating it to a prototype I make a monumental task much more approachable and once it is completed I enjoy those small win. Then I can move onto dessert.

Reminder:

Tomorrow is Coder Nights from 6pm to 9pm. Please RSVP on Eventbrite.

[smallsharptools-blog]

Why I Won't Be Jumping Into Swift Apple's new language Swift is all new and still in beta. It looks great and I completely expect it will quickly replace Objective-C as the preferred language for building iOS and Mac apps. But I won't be jumping in right away. I plan on reading lots of blog posts and code shared on GitHub to learn from others and give Apple time to work out the kinks. Over the past 18 months I did a fair amount of experimentation with storyboards and constraints with a lot of headaches and time. Often it came down to bugs in Xcode like one autolayout bug that I shared on YouTube which tripped me up. I shared what I could and logged many bugs with Apple and have been exchanging messages with Apple to provide what I can to fix these problems. I've shared what I have learned on GitHub such as FullScreen and PhotoZoom. Both of these projects use modern techniques with storyboards and constraints with iOS 7 specific interactions. It took a lot of time to get them to work just right and after making several false assumptions and mistakes I gradually learned enough to get the exact interaction I wanted. Learning From Other's Mistakes Years ago I read a book called The Supermen which covered the career of Seymour Cray of Cray Supercomputers. I highly recommend the book. Cray had an uncanny ability to build computers and assemble complex circuits with ease. I learned so much from what I read about how he kept his skills fresh. For starters he always assembled his boards himself and did not have interns do that work for him like other engineers working with him did. He also did all of the binary math for his circuits himself. By staying hands on he remained close to the technology and learned the limits of the hardware and fine tuned his understanding of circuits. One time he was passing by a group of engineers in the office who were working on a problem with a new circuit on the chalk board. They had been stuck on it for weeks. He listened to them explain their problem and he formed an idea for a potential solution. He sketched up his solution on the board in a few minutes and it immediately solved their problem. By doing all of that time consuming work himself he trained himself continually and perfected his skills. Cray also worked with older hardware which the other engineers were no longer interested in using. He would learn from them what worked and what the hardware limits were. He basically let them make mistakes so he could learn from them and then apply what he learned and apply his ideas while carefully avoiding the time consuming experimentation they already went through.

Early Swift Adopters

After working with storyboards and constraints early I am going to take a break this time around and keep an eye on the early adopters of Swift. I am already learning about many bugs and I hope everyone is reporting them to Apple so they are addressed immediately. I will give it at least 6 months before I even consider committing to Swift. If it took over a year for Apple to work out the kinks with storyboards and constraints I expect the kinks in Swift will take some time as well. I am going to follow Cray's lead on this one and observe others and learn what I can so that when I do get into Swift in I will be ready.

I look forward to moving on to Swift. But I will also enjoy learning from others who make the jump before me.

[smallsharptools-blog]

Full Screen with iOS

Working with the top and bottom bars with iOS 7 has been a challenge. But once you learn the tricks you can do a lot of great interactions with them. Foursquare does a great job of leveraging new UI techniques with their frequent app updates. One that I found particularly appealing was how the app shows a photo on a place detail view. As you scroll up the photo goes out of view and suddenly the top bars which had a totally transparent background go completely opaque with Foursquare blue. It's a great interaction which allows for maximizing the height of the screen.

I recreated this interaction along with another one with a project I called FullScreen which I just published on GitHub. I plan on incorporating techniques like these in apps that I am developing. The code which makes the Foursquare interaction work is done with the code below. (Note: I used Hipster Ipsum to generate the placeholder text.) FullScreen.m

[smallsharptools-blog]

CocoaPods Trunk

We've come a long way since the iOS SDK was opened up to all developers in 2008. In the past few years CocoaPods has emerged as the de facto standard for managing dependencies for iOS and Mac development. The history of CocoaPods was just covered on NSHipster leading into the new support for Trunk. What is Trunk? I've been learning to use and publish my own Pods which has been done with GitHub forking the Specs and submitting Pull Requests which are then processed manually by volunteers. Due to the large number of available specs this process was getting to be more resource intensive. I made the move over to Trunk by first registering my MacBook, claiming my existing Pods and then pushing a few I had not taken the time to submit yet. Now it is just a single command which validates my podspec and makes it available to everyone. (You may like PhotoZoom.) The guide for Trunk will step you through these processes to get you going. It is a far simpler and faster process than before. JSON Format I also noticed that the Specs have all been converted into JSON format. I am happy to see this change since there are so many JSON libraries for many platforms while Ruby syntax is not readily readable or writable from all the same languages and platforms as JSON is already. I hope that this format change facilitates other tools to work with Cocoapods beyond the Ruby language.

Photo Credit

[smallsharptools-blog]

Too Busy To Learn

The thought occurred to me recently that I have been too busy with work to actually learn anything new, but I soon realized that I am constantly learning. Just this month I started to use a couple of new tools which have been a huge helps with m work with building iOS apps.

Reveal for iOS First is Reveal which is a Mac app that allows me to peak into how the views in my iOS apps are assembled. It which works with a library that you embed into your iOS app to allow for traversing the view hierarchy and displaying the details from the Mac app. You can even manipulate values live and see the changes in the iOS Simulator and on a device. It is very much like web developer tools in a modern web browser but for iOS.

Years ago when I used FireBug to manipulate web pages for the first time I thought it was incredibly powerful. I find that Reveal is even more so since I cannot just view the source for an iOS view hierarchy and figure out how it is all assembled. This tool allows me to dig around and visualize everything in 3D and make tweaks just like I have done for years with web development tools in Firefox, Chrome and Safari.

Yesterday I used Reveal to reposition map pins to point directly to the coordinate on the map by adjusting the center offset of the map annotation view. Getting the offset position just right and then using those values in the code sped up the process considerably. I am happy to have Reveal in my toolkit. It is going to save me a lot of time and prevent many headaches.

PaintCode 2

This past week I also learned that PaintCode released version 2. In the previous version you would edit a single drawing at a time and copy/paste the generated code into Xcode. Now PaintCode allows you to manage a collection of drawings, colors, gradients and powerful new features like variables and elements to generate what they call a StyleKit which is a complete class that can be exported into the folder with your Xcode project. The variables, expressions and colors have been especially powerful and I plan on going into more detail once I have the time to pull together more details as well as publish a demo on GitHub.

What has been especially great about this PaintCode update is the helpful support that I have been getting. I have exchanged many emails to relay bugs and feature requests and the team at PaintCode has been very responsive, often getting back to me within minutes. I expect these bugs will be fixed soon and the features will also be considered and possibly available in a coming release. It was well worth the price for the app.

With this PaintCode update I have completely changed my workflow and I know it will cut down on the time I have to manage images.

CocoaPods

I have also continued to work on better understanding CocoaPods in multiple ways. I've added podspecs to several of my existing GitHub repos including PhotoZoom which I updated for iOS 7 and to also use a Collection View instead of the dated solution I built it with originally. The demo app now works much better than the previous version and with CocoaPods it is very easy to add this functionality to another app, which is what I did immediately with the work that has been keeping me so busy. To publish my podspecs I had to fork the main CocoaPods Specs and send back Pull Requests. While I do this often with repos on GitHub this was a different experience. It is not really code since it is configuration files and the repo acts like a massive database for CocoaPods. It one reason why it has been very interesting learning how CocoaPods works. It is a powerful tool with a few rough edges which is improving all the time. GitHub Emojis

Perhaps the most important thing I learned recently is that now in the Mac client for GitHub I can use emojis in summaries and messages. That is a real game changer. ;)

May Coder Nights

Time has flown by so quickly this past month. I cannot believe tomorrow is already another Coder Nights. Please RSVP on EventBrite if you plan on attending. I am happy to show you a demo of Reveal, PaintCode, CocoaPods and chat about the season finale of Agents of SHIELD when you arrive. See you then.

[smallsharptools-blog]

Opening Lyft

Lyft is now operating in Milwaukee and I was curious how I might go about integrating with Lyft. The most basic feature would be to simply open the Lyft app if the user has it installed or instead open the App Store so they can install it. That is what the method shown below does. Opening another app on mobile has been possible for years yet few apps do it because app developers don't often support these features or publish the details to make it possible. Facebook is looking to change that with Applinks which works for iOS, Android and even Windows Phone. Once Applinks takes off it will be possible to deep link into other applications with little effort. Right now you have to dig to find apps which support this kind of functionality.

When I build out iPhone apps I always include the option to at least open the app and when it makes sense I support deep linking. One example of deep linking can be shown with the app for Marquette University. On your iPhone put the URL marquetteedu://maps?q=parking into Safari and tap the Go button. It will open the Marquette app, go directly to the map and pre fill the search for parking. Cool, right? Beyond simply opening the Lyft app it would be great if I could specify my destination and request a ride all in a single tap. When the Lyft app opens I do not have to type in the location I was just viewing in the other app. An app like Yelp could put a button on the profile page for a place to make this an option for their users and it would be great for the user experience for both apps.

Also included below is a JSON file which includes all of the cities where Lyft is operating. By reverse geocoding the user's current coordinates you can get the city, state and country to look up in the JSON and display Lyft integration features only in the locations where Lyft is operating.

I will have to get Applinks features set up in all of the apps that I maintain so that other mobile apps can deep link into them. This is done by adding meta tags to the related website so that the details can be programmatically read and used to open a mobile app with the same content, effectively deep linking into the app. Smart Banners for iOS work in a similar way while Applinks appear to be taking it quite a bit further. In the sample method below the Facebook App ID is used to open the app. For any app which supports Facebook login it requires this URL Scheme to be defined. This is how I can detect if the Lyft app is instal installed and then open it. In addition to the Facebook URL Scheme the Lyft app could define their own URL Scheme, such as lyft:// and deep linking features such as specifying their destination. Another reason to support deep linking with a custom URL Scheme is to pass in the promo codes which Lyft gives out so that users do not have to type it in when another app sends the user to the Lyft app to use that promo code.

OpenLyft.m

LyftLocations.json

[smallsharptools-blog]

Coder Nights Breakthrough

Last night was the 5th Coder Nights at 96square which was joined by Milwaukee’s NSCoder Night. We also were visited by a young boy who was interested in learning about technology. Yesterday I received an email from his mother and she explained that she was sending her son with his father to join us for Coder Nights to get him started. They did not know what to expect. I saw the two of them as they walked in and a short while later I set them up to work with Aaron Hartwig who would take this young boy through lessons on Code.org. This was his first experience in writing any code at all. They went through several lessons, wrote many lines of code and his father followed along with his son. While they were doing the lessons I emailed his mother back to let her know that they had settled in and had started these lessons and I was sure she would hear all about it from her son. Later I got an email back. She wrote that her son had the biggest smile on his face when he saw her. He gave her a high five and a big hug. He’s really excited to continue learning about technology and software development. She called it a breakthrough. I expect she has been looking for a way to support his interest in technology and this was a big help. I think we can all relate to that experience of getting our first taste of working with technology. When you first realize that you can make the computer follow the instructions that you wrote it is so exciting. That light goes on and you know that you can keep learning and do more and more. I am excited for him to continue learning. His mother calls it a breakthrough for him. It’s a breakthrough for Coder Nights too. I thanked her for being such an awesome mom. Yay mom! The next Coder Nights is May 20th. You can RVSP now. Summer break is coming up fast so if you know any high school students who have an interest in learning about technology and software development we are happy to take them through these lessons and show them how they can continue learning at home. We would also like to invite others to become mentors to others attending Coder Nights. It is a great experience teaching someone like this little boy who’s world opens up with possibilities once they realize this is something they can do. Discussing your work with other experienced developers can also be very helpful. Coder Nights is like those conversations you have in the hallways at conferences when you learn even more than you do while sitting through long presentations. I’d like to thank Aaron Hartwig for taking on the role of mentor last night and codeorg for providing great lessons that made it a great experience.

[smallsharptools-blog]

Easy Password Management

After the Heartbleed fiasco everyone should be changing their password on just about every service they use. A given service may not be compromised, but many people use a common password across multiple services as well as usernames. We do this because it has been a real chore to manage all of these passwords. This is why logging into a new service with Facebook is such an appealing option. Even if you do not want to use Facebook for anything else it is still helpful to have account just to make it easier to log into a wide range of websites and mobile apps. Managing passwords does not have to be hard and you do not even have to pay for an app to do it. A recent addition to OS X and iOS is the iCloud Keychain. For years I have managed my passwords with Keychain Access on the Mac. With iCloud Keychain you can sync your passwords from your Mac to your iOS devices like your iPad and iPhone. This way you can reset your password and generate a strong password which you do not have to remember since you can set it on your Mac and retrieve it from your iOS device. If you use Safari, as I have been recently, you will find that when you create an account or change your password sometimes Safari will offer a uniquely generated strong password for you which will then be stored in your keychain. What About My iPhone? Until today I did not know how to retrieve my passwords on my iPhone or iPad. You can get to your iCloud synced passwords in Settings. Go to Safari > Passwords & Autofill > Saved Passwords. From there you can select one of the save passwords, enter your pin to display the account details including your password. To copy the password so you can use it in an app just hold your finger on the password and you will see a pop-up to copy the password. You can then paste it into the password field in an app. Changing Your Passwords Here is an example of how you can change your password with Twitter. Start out on the password page in settings. For me Safari filled in my existing password and then once I selected the new password field it presented a generated strong password which I selected and it filled in both of the fields. You can also used the online strong password generator if your browser does not do this for you. Remember the first 2 characters for the generated password for a moment. Next I had to click into both fields to get the Save button to become active. Now my new password should be stored in my keychain and quickly synced via iCloud. I then go into the Saved Passwords screen in Settings for Safari and scroll to find this account for Twitter. I see there are 2 accounts with this username with one still showing the old password and the other with the new password. You can identify the new password with the 2 first characters you remembered from the generated strong password. I deleted the entry with the old password and copied the new password. Since Twitter is integrated with iOS I can change the password in Settings under Twitter for that account. I select that account and paste in the updated password and tap Done. It verifies the password is correct and displays checkmarks next to each field to let me know everything is good to go. That was very easy. For any other app, like Mailchimp or Bitly, which is not integrated with iOS, you can simply open that app and change the password there by pasting in the new password. This way you can use unique and strong passwords for everyone account and never have to memorize them.

Managing Keychain Access

You will see there are many passwords stored in Keychain Access including many which appear to be duplicates. Most duplicates happen with websites which have various pages which prompt you to log in. Each entry on you keychain is likely with a different page, like the Twitter Sign Up page and the Twitter Log In page. Since you won't ever log in with the Sign Up page you can safely delete that entry and just leave the other one for the Log In page. In Keychain Access there is a search field at the top right of the window. You can use that to filter the list of password entries. If you have multiple Twitter entries you can filter to just those by entering "twitter" into the search field. That will narrow down the list. This same feature is not available on iOS so it will be much easier to clean up your keychain on your Mac. Many of the password entries were simply named "twitter.com" which was not helpful when I have multiple Twitter accounts. As I went through these entries I either deleted redundant ones or set the name to something like "twitter.com (smallsharptools)" so I could see which Twitter account that password accesses. You will also notice that some entries are on the iCloud keychain while others are on the login keychain. This is an artifact of the pre-existing login keychain and the new iCloud keychain. It can get mixed up and confused. You will find entries on the login keychain are out of date while the iCloud entries are more current. When you see older entries on the login keychain you can safely delete them.

Of course you can always use the password reset feature of any website or mobile app if you do forget or lose a password. It is better to fail to save a newly generated strong password then to share a weak password across multiple accounts, so don't worry about what you need to do if you lose a password. Just don't lose or forget your password for your email account! You will normally have a way to reset the password and save the new password to your iCloud keychain.

Multi-Factor Authentication

That's a complicated sounding thing, but it is fairly simple. Basically when you log into Facebook you will use a secondary step to verify your login. For Facebook you can turn on Login Approvals which will send a code to your phone which will complete the login process. Since you log into many websites and apps with Facebook it is a good idea to turn on Login Approvals with Facebook. You may want to do the same with other important accounts like Twitter and GitHub which also allow you to log into other services with those accounts. With Facebook you can view all of the apps which have access to your Facebook account on the App Settings page. You can review these apps and click Edit to view all of the rights you granted to that app and even revoke some of the rights, like revoking access to Flickr so it cannot post on your behalf. Twitter, GitHub and other services which allow you to log into other services also have these app pages. See Twitter applications and GitHub applications, for examples. Feel free to revoke access to any websites or apps you really do not use anymore. You can always grant access again later. It won't delete the account on the other service. It just removes access to this service.

Change Your Passwords Regularly

You really should change your passwords once every 3 to 6 months depending on the sensitivity of your account because even if you log in securely that communication can be monitored and with enough time and computational power that communication can be compromised which will reveal your password. For the fastest computers this can take many months, so changing your passwords will ensure that even if you are being targeted that by the time the communications have been compromised the password they get will be outdated already. This is why companies require employees to change their passwords regularly. It may not be as critical for your Pinterest account, but if you manage a Twitter account for a big company you may want to change the password regularly because that account is much more likely to be targeted. Photo Credit