As I mentioned previously (see this post), I am taking on the 100 days of code project this year. I started my Swift powered iPad application last week, this post covers the first 7 days of my work. Importantly, I am also open-sourcing all the code for you to make fun of and use. But I’ll add that if you make millions from it, spare me a few pennies 🙂
The first thing I did was clone the 100 days repository from Github and change the files as per the instructions. My first mistake I believe was adding my code to this project, having realized that might be a problem, I went ahead and created a separate repository for my code. Now that both are separate it is way more manageable and Github shows daily commits. From that point forward, I have only had to edit the log file in the 100 days repository.
My code repository is an Xcode master / detail application, although most of the template code was ripped out ready for me to start.
With these steps done, set-up was complete. My daily workflow consists of
- Edit code for the application.
- Commit that code to Github.
- Edit the daily log file.
- Commit the daily log file to Github.
- Tweet daily with a link to the repositories for others to read.
Tools I used
- Xcode 8
IDE and compiler.
- iPad Pro
I have worked on iOS Swift applications before so this is not all new to me, however there are some things I want to note. Most of them are things I had forgotten due to not using the techniques in a while.
- Relying on Xcode to get the auto-layout constraints right for you is a lottery. Some times it will do a great job, other times it will end with you removing them all and starting again.
- When using a master / detail view set-up, remember that you’ll have to take in to account navigation controllers for segues and other transitions.
- Writing a custom class for viewControllers is almost always a good thing as you are bound to want to do some custom code at some point. So you might as well get them in now and add code later.
- Optimizing code as you go might not be what you want to do, personally I prefer to get things running and then refactor later as it either presents it’s self or when the time feels right.
- Small functions are ALWAYS the way to go for maintaining code and keep possible bugs to a minimum. Plus you also get a nice toolset as you build the code base.
- This is just a suggestion, get UI elements in place even at the cost of things looking ugly at first. This will let you get to the code faster, there is always time to make things pretty later on.
In the coming week, here is my planned progression.
- Get note editing working.
- Get note deletion working.
- Replace the test data with actual notes (no permanent storage just yet)
- Start considering how the data will be stored between usage. This will take a while and may require several testing sessions to see what kind of storage is going to work best with the lowest resource overhead.
Follow My Progress
You can follow my progress via the following
- Twitter: @CompileSwift
- Github: 100 Days of Code Repository
- Github: Application Repository
- Medium: Compile Swift Publication
- On my web site as I blog my weekly progress
So that is the first week done, maybe not as much code as I would of liked, but a solid start.
If you are working on the #100DaysOfCode, I’d love to hear your thoughts and reports.