The Mobile Startup: Episode 1 - Intro & My Mission

Intro

I'm starting a new blog series that I intend to continue for a few years, where I will describe my whole experience building a technology startup from scratch.  I am a software developer now running my own, brand new company with a lot of ideas for apps and projects which I am now developing one at a time. 

- A very casual series where we will discuss: business strategy, picking your battles, marketing, software development practices, implementation of ideas, project management and other fascinating insights about the market.  
- We will focus on the mobile field, marketing and other tech opportunities.  
- We will start with creating simple iOS applications from scratch, and documenting our progress with periodic updates. 
- Anyone can ask me questions and learn from my mistakes, as the operation grows.  
- You could also give me hints, if I get stuck, if you want to share your own experience. 

About Myself

- My skills include: programming, project management, leading small teams, playing jazz guitar/piano, video/audio production, recording and singing.
- I am a 34 year old software developer from the Toronto area.  
- I went to college in Toronto for Computer Science taking taking 9 semesters in total, including a 2-semester co-op term.  
- Graduated in 2005, and since then I have had 10 full time programming jobs without taking any breaks in between, other than vacations.   
- The last 3 gigs have all been contract, since I started consulting.  
- I've been involved in many practices:  client, server, mobile, databases, operations support, software design, implementation, outsourcing, leading small teams, but mainly programming. 
- I have settled into specializing in iOS architecture, because I enjoy the Xcode environment and like the iPhone and the apple ecosystem.  
- I am however interested in pursuing the following areas: content creation, social media marketing, big data and statistical analysis, web 2.0, android, wearables, IoT, VR, Blockchain and other future cutting edge tech.  

Key Intentions: 

- Keep projects as simple as possible
- Focus on best practice, clear UI design
- Clear definition of features and problems
- Targeting the mass global market.  
- Accelerating the rate of development, by building a set of generic automation tools and a shared codebase that can be reused.  
- I am new to social media marketing, but I will be be documenting the process of learning and practicing marketing from the perspective of a software professional. 

Starting Portfolio

JamCat App   - band activity, song list, and set list manager.  Website and iOS app that organizes bands and everything they know how to play.   This took me a few years to build. I'd say there are over 1000 hours invested in this app part time since 2012. 

https://itunes.apple.com/ca/app/jamcat/id642035970?mt=8,  http://JamCatApp.com

Song Transpose - An app that helps you move chord progressions up and down, ignoring everything else contained in a song profile.  This was a 3 week project.  It made 70 sales so far, without any promotion effort whatsoever.  

https://itunes.apple.com/ca/app/song-transpose/id1041703038?mt=8

Meow Pix - a Relaxation app containing images of cats, classical music, sound effects, and other features.  This only took 3 weeks to build.   A 45 hour effort. 

https://itunes.apple.com/ca/app/meow-pix/id1205087427?mt=8

- These apps are just the starting point, used as a learning platform for marketing. 
- I will keep open to building ideas in sectors other than mobile, however, the scope is to be kept minimal, to fit an MVP format. 

In the next episode I will describe my current strategy and brand new set of projects that I'm working on, as well as others that are in the pipeline.   Also look forward to an occasional vlog on my YouTube channel:  http://youtube.com/FranticRock

Cheers,

Alex

My take on software quality, common pitfalls, and the mindset for success.

Common Pitfalls

This article applies to all branches of software development, and is my view on software quality, based on 12 years of experience as a software engineer.  We will be looking at common pitfalls, and how they can be addressed by a particular line of thought or strategy. 

What makes software projects have poor quality and grind to a halt, or have costly production defects?  Based on industry feedback, some of the following symptoms are causes of software failure: 

1. Insufficient attention to detail and care for the code.  (Patch on patch, fixing only immediate symptom, without understanding root cause). 
2. Lack of proper object-oriented architecture (resulting in ever increasing complexity of code). 
3. Copy and Pasted code (violation of DRY)
4. Improper design (violation of SOLID)
5. Poor coding practices (huge methods, too many conditional statements or "accidental complexity")
6. Separation of concerns missing. (Grouping many duties into one method, class, object, event or variable. ). 
7. Unclear definition of concern separation. (Not sure what is the single responsibility of each class, method, variable, object, etc) 
8. Unclear / ambiguous naming of variables / objects.  Names not specific enough, resulting in need for comments. 
9. Fear of refactoring.  Fear of making changes.   (Afraid because we are not sure what is broken after making a change). 
10. Lack of or complete absence of unit tests, resulting in no way to cheaply have assurance of correct behaviour upon making changes. 
11. Inability to "Step Back" and ask really difficult and uncomfortable questions.  (Should we even be doing this?  What's the benefit?)  - Tunnel Vision. 
12. Lack of "Ownership" of the code.  Afraid to change.  Unwilling to figure out how it works.
13. I'll remember to do it later.  It's fine for now. 
14. I really want to learn this new thing, so i'll use it, even though it's doesn't quite fit. 
15. Accidental complexity allowed to continue unchecked. We keep adding features without thinking about design and making the code easy to re-use and grow. 
16. The "Not enough code" syndrome.  Now we all know that "less code is better", mainly for maintenance reasons.  But actually, a lot of the time, you need to have a lot of code in order to fully address the requirement, and do a good job implementing the feature you envisioned.  Things are often simple on the surface, but you need to have a great UX and cover all the edge cases.  So you might need to write a lot of code.  Just make sure to architect it in a way that makes it all separated by responsibility.  Don't compromise on that.  Ask yourself: "Does this software suck because we didn't fully flesh out how it should work?" 

Strategy for Success

So how do we not only avoid the above grim situation, but on the contrary: achieve the complete opposite?  We reverse each point above into its' positive counterpart: 

1. Meticulous attention to detail in every line of code we write. (We should be proud and confident about our code.  We can easily speak about the decisions we made and their justifications. Not:  "it sorta works, i guess". ). 
2. Think through the design of every feature first.  Even if its' a minor feature.  Examples:
   1. Do i put this in the view controller?
   2. Is this likely going to be reused later by someone?
   3. Can it be made completely generic?  What's the extra effort in doing so? 
   4. Does adding this increase the complexity of the class where we are adding this? (and thus it's $$$ maintainability)
   5. By adding my code, did i just make the object do more than 1 task?
3. Is this task already done somewhere else?  Is it in multiple places?   Can i take it out of those various places and instead put it in one place, and reuse that?   
   1. Doing this for every feature you implement continuously improves the overall strength of the code base. 
   2. Notify other developers of these reusable resources:  building up your team's "Toolbox".    ("Hey, i made this category which makes sure things are done on the main thread, with one line of code!") 
4. Refer to wikipedia, on SOLID definition.  (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design))
   1. In Pull requests, the reviewer, can asses each of SOLID's properties, to check for violations.  Fix at PR stage. 
5. Enforce the following guidelines:
   1. Methods can only be 20 lines of code or less. 
   2. Classes must be 700 lines of code or less.  (If exceeding this, start making component classes out of your class with Roll-Up objects, that can just be used with a few lines of code - Facade pattern). 
   3. Nesting (If, switch, loops, blocks), not more than 2 levels deep.  (3 levels deep or more = you must break it up into separate methods). 
   4. Single responsibility for every object.  Few exceptions are:  Facade class which manages other objects, but know little to nothing about how they work internally. 
   5. Rely on abstractions in areas which are likely to change.  (In other words: if something is likely to change, put an interface around it, with a simplified entry point to the functionality).  I believe abstracting everything is a waste of time though.  So the judgement call is:  What is most likely to change? 
6. What is the primary responsibility of this class (every class)?  The answer should be provided in one short sentence, always. 
7. We should first define what the different "Concerns" are, and then consciously place classes into those buckets.  
   1. For example, responsibility can be separated into into: 
      1. Networking
      2. Navigation
      3. Persistence
      4. Generic Views/Controls
      5. Business Specific Views/Controls (can reuse Generic Views internally) 
      6. View Controllers (screens comprised of components) 
      7. Components.  (More complex than just a view or control.  It's a business-specific UX piece that does a single job). 
      8. Utilities.  (Many categories here.  These are always generic and reusable.  Do not know about business rules, that are likely to change). 
      9. Configuration
      10. Styling (Style sheet)
      11. Localization
      12. Accessibility
      13. Analytics
      14. Validation
      15. Alert / Dialog utilities
      16. Resource / media access  (really easy way to access images from network or local)
8. "Take that comment and make it a method".  
   1. Then put the code into that method.  
   2. Voila = self-documenting code. 
   3. It's OK to have long method names (within reason).  
   4. If the name is too long, then is it doing more than one thing??
9. The more you do refactoring as you implant features, the easier it will become.  Just like any skill - it's acquired over time.  I believe refactoring should be constant, as development continues. 
10. Let's say you have 600 unit tests.  You can run them overnight on all OS versions, example: iOS 8.0, .1, .2, .3, iOS 9.0, .1, .2, .3. iOS 10, etc...   You will uncover edge cases on specific iOS versions using these tests.  You would have to have an entire QA department, and QA manager distributing work for them, to do this manually.  The cost would be 100 times or 1000 times more. 
    1. There definitely is a trade-off overhead in managing the tests, and setting up the CI for the first time.  But the act of managing the tests does give you extra insight into the state of the code.  (Reality check - what did i just break?, or how can the architecture be improved?). 
11. The best code is No-Code  (guaranteed bug-free!!).  If you can avoid implementing something, just make the decision not to, and justify it objectively.  Some business requirements go away by themselves.  This is because assumptions get dispelled, and stakeholder input causes initial claims to be invalidated, making some requirements obsolete.  Example:  Your customer later tells you: "We actually can't have this feature because it violates privacy regulation number N".   
12. "I just have to implement this one feature", i will just do it.   I can first check whether it's done similarly somewhere else.  I can ask another developer about it first.  Maybe someone in the department already delved into a similar task.  I shouldn't be afraid of making larger changes than what I planned.  Refactoring can improve the maintainability of the code. 
13. Fact: The cost to fix bugs grows exponentially the later they are detected.  Example:
    1. Cost to fix in dev: $10
    2. Cost to fix in QA: $100
    3. Cost to fix in UAT: $1000
    4. Cost to fix in production $10000 or more.
       
       It's also better to leave the code in the best state possible, so other developers don't have the cost overhead of asking about what's going on.
14. Using tech just because you want to put it on your resume is selfish, because you can just implement it simpler using standard tools, but using SOLID.  "A new co-op student should be able to figure it out".  
15. Keep making easy to use facades in the code, abstracting away complexity.  Keep refactoring the code until it fits into the following set of guidelines: 
1. Methods can not be longer than 20 lines of code. 
2. Classes can not be longer than 700 lines of code. 
3. Nesting of If statements, loops or scope levels can not be more than 2 levels deep. 
16. Perhaps the implementation could be improved.  Sometimes this includes a lot of effort, R&D, or sheer brute force coding, but as long as the code is structured properly, it's OK to have a lot of code.  (Just think of a piece of software like MS Office, and how much code it has).  

Learn how to create your own Programming Language here!!

What does Playing an Instrument and Computer Programming have in common

I am a guitar player and a computer programmer.

I enjoy designing and coding software, as well as improvising on the guitar, particularly in the jazz, rock and fusion styles.  I've been thinking a bit about how music and programming actually have a lot in common. These 10 things are just the aspects that jump out at me, and may not necessarily work for you.

1. Math at the Core: Computer programming uses math concepts to improve efficiency of code, such as when you're looking for an algorithm that executes in less time for your particular scenario, uses less memory, or CPU cycles.   Music theory uses basic arithmetic to define intervals between notes, that correspond to various tension levels you want to express.  Math in this case is used as a form of self expression.  Even if you are not aware of what a certain set of notes is expressed in mathematically, that math relationship is always there in anything that you play or listen to.  Same applies to software, which always winds up as ones and zeroes at the finest level.  


2. Patterns and a Taxonomy to learn: Computer programming has logical patterns to organize and categorize the concepts you know:  classes, interfaces, design patterns, variables, enums, structs, methods, wrappers, adapters, pointers, variables, messages, delegates, weak references, data formats, algorithms.  Music theory uses chords, scales, triads, arpeggios, chord progressions / regressions, tonal centers, modal playing, shape thinking, contours, rhythmic variations, dynamics, phrase repetition, call and response, tension, release, mixture of voices, rhythmic displacement, harmonics, and feel to achieve the desired effect.  Both sides utilize these structural tools, each serving a distinct, specific purpose.  They are all, however, just a means to an end.  Being familiar with as many as possible of these is definitely beneficial for both trades.


3. A Problem, and Solution: Computer programming has problems and unknowns. There are many ways to solve a problem, and an infinite combination of steps to get there.   Music has a chord progression that you may need to fill or arrange.  Or you could be trying to fulfill an idea which is just a melody in your head.  How you fulfill it, is completely up to you.  In both trades you often end up solving a problem that nobody cares about, but you have learned something in the process.


4. A Scale of Clear Right/Wrong to completely Subjective.  Computer programming has common "right" and "wrong" ways of doing things.  Some choices are considered wrong, such as gluing SQL strings together, containing user input.  Music has some things that are very "wrong" too, such as playing a Flat 9 over a major chord repeatedly....  But Captain Beefheart would disagree.  Analysis is needed to  understand why a solution is considered "correct" and also that a musical passage is "tasteful" or of "high quality".  These conclusions are based on your personal line of reasoning, preconceptions, and requirements depending on your situation. Finally there is a Scale: A clear right and wrong on one end, and highly subjective decisions on the other.  We all decide differently where to put any given topic on that scale, although many common schools of though exist.


5. Varying standards for Purity and Aesthetic. In Computer programming there is a certain aesthetic to your code. This includes: how clean and efficient it is, and how prone it is to breaking in the future. In music, you can also distill a melody or arrangement to its most essential parts, and subtract redundant pieces, until you're left with something that's "just right".  Some people are much more strict with this aesthetic than others.  How "cleanly" various roles are performed by different software elements can be correlated to how "cleanly" instrument tracks in a piece of music do their job.


6. Knowing limits, breaking rules and common conventions. In computer programming, you may choose to break rules on purpose.  For example, you might DE-normalize a database table, building very specific indexes, so that very specific Select statements are quick to run, because you do not have to do any joins or contend with processes.  In music, especially jazz, you break rules all the time in order to create tension.  In more popular styles, you keep changing the well known rendition to keep things interesting for yourself - the musician, as well as the listener. This often involves infusing diverse influences into the rendition. 


7. Exponential growth in variety. Computer programming has a proliferation of technologies which seem to be exponentially multiplying with the help of the internet.   The number of songs created, new music styles and cultural musical expressions is also exponentially growing.  The challenge for both is keeping up with the trends, and choosing what to even keep up with.


8. Human Interaction is at the core. Computer programming has people you need to work with.  Some of them are very opinionated, overbearing or overly defensive.  The music industry has very similar types of people that you often have to work with.  Both trades, in my opinion, are as much about people skills as they are about the craft.  This human element applies at every stage:  From designers to customers.  From players to listeners. 
   
9. Design determines what you can do.  How you design a piece of software often dictates what your limitations, possibilities and outcomes are in the future.  This applies to music, when you have a rough idea of the style of song you want to compose, the chord progression and the rhythm you have chosen.  It is generally uncommon to have a bunch of completely different, disjointed music styles, rhythms and chord progressions follow one another in the same song.  The "design" of the song must follow some specific train of though, so it can be understood.   The same applies to Software.
    
10. Conventions, Rebellions and Inspiration. Every time traditional thinking is successfully challenged, we all enjoy the breakthrough.  Whether it's a hugely successful commercial success or a very niche following, we all love it when things are done differently on purpose.  If I can wire up 20 raspberry pies to uniquely control my house, or learn about Pat Martino's unique approach to using Minor Scales, I would be excited and inspired by the innovation factor, and the future possibilities.

Learn how to create your own Programming Language here!!

Beer in the Fridge at work

It makes me really happy to join a technology company and find beer in the fridge, people playing ping pong, sleep in sleeping pods, frying up BBQ at lunch, and playing basketball.  Not because these things are inherently fun.  But because, it's a message from management that says the following:

1. We hire such a high caliber of employee, that they would never consider abusing the perks we've given them.

2. Congratulations on finally getting to the top 10% of the best places to work.

3. People here are smart on many levels, not just book smart. They realize the value of maintaining a flexible mind and body.

4. We are all like minded in our pursuit of excellence.  We are so productive that we have plenty of time left over to enjoy the perks, after succeeding at our jobs. 

5. The company is successful financially, and would stop at nothing to satisfy and retain its employees.

This of course results in people giving back more, and feeding this cycle.

Writing Energy Efficient iOS Code

How to extend the user's battery life and improve user experience.

This transcript is from Apple's WWDC14 2-part video: "Writing Energy Efficient Code"

Overview

OSX 10 Maverix and UP, 2 new sections were added:
1. "Apps Using Significant Energy" in the battery indicator on the status bar.
2. "Battery Usage" tab in Settings showing by-app breakdown of battery usage.


Everything on the system uses Energy. Components include:
1. CPU (using a small amount of CPU makes a big difference to energy consumption)
2. Flash storage. (big dynamic range)
3. Networking.
4. Graphics. (A small change by the developer might cause an expensive operation under the hood)


There are 3 states of energy use:
1. Idle power (device is not being used.  apps not running)
2. System Active (your app is running code)
3. Intermediate States. (system is idle, but not able to get back to idle power.  Time is required to achieve this state.)
a. Device stays in this state a lot, if sporadic work is done.
b. This is the concept of "Fixed Cost".  Anytime sporadic work needs to be done, a minimal cost is incurred.
c. Fixed cost tasks (sporadic tasks) consume a lot of energy for the amount of work they actually perform. (high overhead)
d. The solution is: Bundle all the sporadic tasks together in order to reduce the fixed cost of your work.


Energy and Power are 2 different things.
Power is the peak value at a given, instantaneous point in time (measured in Watts)
Energy is the sustained combined energy usage to accomplish a task (measured in Joules)+

Better Performance most times means: Better Energy use

For small workloads, Fixed Cost will dominate
For intensive workloads, dynamic cost will dominate

POWER can be TRADED for ENERGY, for example:  a single threaded workload can be multi threaded in order to minimize the Fixed Cost. (The Dynamic Cost will stay the same)

Techniques:

1. Do It Never  (Avoid unnecessary work)

If another app comes in front of your app, are you still running animation code in your app?
If another view comes on top of the active view, are you still animating the parent view?
Use:
- (void)applicatioNDidResignActive
- (void)applicationDidBecomeActive
or listen for UIApplicationWillResignActiveNotification

Pause Timers and animations when resigned active.

2. Do It a a Better Time

If you expect an expensive operation such as downloading a huge update or content.  Schedule the work when the user is plugged in to a power source.
OS10 Yosemite has NSBackgroundActivityScheduler schedule things like:
- Periodic content fetch
- Update install
- Garbage collection and data maintenance tasks
- Automatic saves or backups

OSX:
1. Create an NSBackgroundActivityScheduler object with a reverse-dns Unique Identifier.  Re-use these identifiers for the same activity.
2. Set the tolerance  (in seconds.  600 = 10 minute from now start)
3. Set the interval (Execute every interval.  Tolerance applies on top of this)
4. Set reapeats = YES (if you want it to repeat)
5. shouldDefer (allows deferring work until the best time)
Interval will execute it once each Period (not at the same time each time).

Call activity scheduleWithBlock:...

NSURLSession Backround Session:
ou pass a bunch of NSURLRequests to the background session, and they will get executed Out-Of-Process on a System Daemon.
Delegate callbacks work as usual with NSURLSession
If your app gets terminated, your tasks will still be executed by the OS, and when App is re-opened, you will
retrieve your existing session by it's unique string ID, and you will get delegate callbacks also.

iOS7 and Up, you can set configuration.discretionary = YES;   (System picks the best time to do the work)
This provides bandwidth monitoring and automatic retry. (if bandwidth drops below minimum speed, task is paused and retried later. Handles edge cases for you)

3. Do It More Efficiently

iOS8 and up, has "Quality of Service Classes"
1. User Interactive (main thread interactions) - Is this work actively involved in updating the UI? Animations, input event processing...
2. User Initiated (Immediate results) - Is the user waiting on this content before next Interaction can be done.
a. Is it OK for Usre Interactive work to happen before my work?
b. Is it okay for this work to complete with other User Initiated work?
c. Is it oka for my work to take precedence over Utility work?
3. Utility (Long-running tasks) - Is the user aware of the progress of this work. Does it show a progress bar?
4. Background (Not user visible)

(This is a hierarchical priority)
The system prioritizes higher level tasks over lower level tasks..


Practical Example: Imagine we have a Grid View app with image thumbnails being imported and loaded:
1. User Interactive would be the Scrolling only (main thread)
2. User Initiated would be the Thumbnail Generation, and Image loading when clicked.
3. Utility would be Image import and conversion (progress bar shown)
4. Background would include search indexing.

Powermetrics tool can be used to see which QoS are in use. 

usage:  sudo powermetrics —show-process-cos —samplers tasks

Gives the MS per sec usage breakdown of each QoS class for your application. 

To see which QoS class is used while debugging: 

• Pause in debugger. 
• Go to the CPU tab to see breakdown of threads. 
• You will see all the different threads and resource usage of each. 
• For each thread it also shows the QoS class under the thread name. 

Spindump tool can be used to see which QoS is used to execute particular code. 

usage: sudo spindump -timeline MyApplication

Gives you the history of which QoS was used over the lifetime of the execution of your code. 

When the user is not actively interacting with your application, you want to aim to have 90% of all work to be at Utility or Below.  

4. Do it less:

CPU:  

1% CPU usage causes 10% higher use over idle

10% CPU usage causes 2x power draw over idle

100% CPU usage causes 10x power draw over idle. 

• CPU use has a huge dynamic range in power.
• Minitor CPU use with Xcode debug gauge
• Intruments’ Time Profiler is the best tool to use for monitoring CPU usage. Gives a stack trace breakdown by CPU usage. 
• Performance Unit Tests can be used to detect Performance/Energy regressions.  

Minimize Timer Use in the application:  to minimize the Fixed cost overhead associated with them.

Timer types:

• NSTimer
• CFRunLoopTimer
• pthread_cod_timedwait()
• sleep()
• GCD timers
• select()
• CVDisplayLink
• dispatch_semaphore_wait()

Use the # Wakes tab in the Energy Impact tab to find out how many times the app awoke due to a timer firing on average per second. 

sudo timerfires -p MyApplication -s -g 

Helps see all timer firings inside the app. 

Timer Coalescing:  Groups timer executions together, according to a maximum tolerance you specify.  Examples:

[myTimer setTolerance: 60.0];

CFRunLoopTimerSetTolerance(myTimer, 60.0);

dispatch_source_set_timer(my_timer, DISPATCH_TIME_NOW, 30 * NSEC_PER_SEC, 60 * NSEC_PER_SEC);

This grouping of timer executions improves the fist cost of energy consumption. 

• Be mindful of wakeup overhead
• Monitor for wakeups
• Debug with timefires
• Specify timer tolerance

Graphics:

• Avoid extraneous screen updates
• Unnecessary drawing kicks graphics hardware out of low-power modes
• Drawing more content than needed causes extra power draw to update the screen
• Use needsToDrawRect: or getRectsBeingDrawn:count: methods to fine-tune drawing

In Debug options you can enable: “Flash updated regions” to visually see which regions are being updated, to check whether all those updates are necessary. 

If you apply a translucency or blur effect on an element that has other elements behind them that frequently update, this is an expensive graphical operation.  Better to ensure that frequently updated content is not behind any elements that have transparency effects.  (Avoid Blurs on updated content)

Storage:

• Writes to flash are much more energy hungry than reads
• Write the minimum content necessary
• Aggregate the writes for better efficiency. 
• Any I/O will pull device out of low-power states. 
• Use caching to your advantage. 

Writing Energy Efficient Code Part 2

Recap: 

The Fixed cost of any resource is due to the fact that the resource stays powered on for a while after performing work, in case its’ needed for more work in a short period of time.  If no work is performed, then the resource is powered back down after a while.   

Trading Power for Energy is generally a concept of Using higher power in a shorter amount of time in order to minimize the Fixed cost of the work performed.  (thus reducing the total energy used) - “Do as much work as you can quicker, minimizing the overall energy used”. 

• Do it never
• Stop unnecessary work on app transitions
• Do it at a better time
• Scheduling with NSBackgroundActivityScheduler / NSURLSession
• Do it more efficiently
• Set appropriate QoS work priority
• Do it less
• Coalesce your timers

CPU Monitor:

Throws an exception if over-normal type of CPU usage is observed.

Example:

Exception Type: EXC_RESOURCE

Exception Subtype: CPU_FATAL

Exception Message: (Limit 80%) Observed 89% over 60 seconds. 

Catches “Runaway background usage"

But this won’t catch normal use which is happening in background, in times that it should not be.   

Energy efficient Animations:

Review your Blur usage and reduce frame changes behind blurs. 

Avoid extraneous screen updates. 

Energy Efficient Networking

• Lots of small calls has the Fixed cost of keeping the radios ON over a period of time  (Overhead costs).   In this case, the overhead cost is very high in proportion to the amount of packets sent. 

• Not all means of network transfer are the same.  For example: 3G web browsing for example is more expensive than WiFi. 

Conditions affecting network battery use:

• Celliar vs WiFi 
• Signal conditions
• Network throughput

Solution 1:

• Buffer data together and send as batch.   (Coalesce transactions)

Do it less/never 

• Reduce media quality
• Compress data

Avoid redundant transfers

• Cache data
• Resumable transactions  (or chunked transfers

Handle errors:

• Timeout
• Retry policies

Consider tolerance (doing it at a better time)

• Understand the requirements - when really is it needed?
• Consider technology used
• Check network conditions before sending. 
• Check data before sending it to make sure something actually changed. 

NSURLSession allows:

• Pause/Resume
• Caching with (NSURLCaching)
• Background Sessions - out of process transactions

NSURLSession Example:

NSURLSessionConfiguration *config = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier: @“com.apple.App.UserRestore”];

[config setAllowsCellularAccess:NO];   // Will only use WiFi - save the user money

[config setDiscretionary: YES];   // Take care of the task at any time within the window

config.timeoutIntervalForResource = 18 * 60 * 60;  // Within the last 18 hours. 

…  Now make the session and task with this config as normal.  

Summary: 

• Coalesce your transactions
• Coalesce your transfers
• Consider tolerance

Measuring Impact:

• Developer menu on the device now has an Instruments option where you can start recording an energy trace.
• Then “Import data from device” to load this file .
• Apps can also force display brightness to maximum. Make sure this is only done when absolutely necessary. 

Sleep:

“To sleep is to prepare for the longer journey ahead”. 

“The longer you allow your devices to sleep, the better the battery life”. 

Background best practices:

Notifications:

Device does wake up in order to send the local notification or push notifications. 

• With Push Notifications, you can set the push priority.  (10 is default - immediately. 5 - Delivered at a power conservative time). 

VoIP

Previous to iOS 8 was Periodic keep-alive packets causing device wakes, and code complexity. 

As of iOS8 the PushKit framework now allows using the Push Notification service to talk to VoIP apps:

• No persistent connection required. 
• app relaunched if terminated
• include up to 4k payload  (much more than the 256 bytes with regular pushes)
• app runtime to process the pushes. 

VoIP Push example:

#import <PushKit/PushKit.h>

- (void) voipRegistration {

PKPushRegistry *voipRegistry = [PKPushRegistry alloc] initWithQueue: dispatch_get_main_queue()];

voipRegistry.delegate = self;

voipRegistry.desiredPushTypes = [NSSet setWithObject: PKPushTypeVoip]; // register

}

NOTE: VoIP Background mode needs to be requested for this to work. 

Delegate methods:

1. Handling push tokens

- (void) pushRegistry:(PKPushRegistry*)registry didUpdatePushCredentials:(PKPushCredentials*)credentials forType:(NSString*)type

{

    // Register push token with server. 

    // There will be a separate token between VoIP and Push notifications. 

}

- (void) pushRegistry:(PKPushRegistry*)registry didReceiveIncomingPushWithPayload:(PKPushPayload*)payload forType:(NSString*)type

{

    // Received push

}

On the server:

1. Request the VoIP push certificate on the apple portal
2. iOS8+ only.  

Location Optimizations:

• Example: Location based restaurant suggestions. 
• [locationManager startUpdatingLocation] will keep your device ON continuously. 
• Accuracy affects energy use. (more precise is more energy used)
• Only use this when necessary, and turn off continuous updates when not needed. 
• Make sure to Turn OFF location Updates when not needed. 

If you don’t need GPS level accuracy: 

• locationManager allowDeferredLocationUpdatesUntilTravelled:timeout: 

(Only notifies if you moved a certain distance)  500 meters or 5 minutes for example. 

Example: Weather app. 

Region Monitoring:

• When entering or exiting a specific location.  
• Set up a specific region you care about.  App is only woken up when condition is satisfied. 

Significant Locations Visited API

BLE

Peripheral-side buffering can be used to only wake the device when the peripheral’s buffer is full. 

Can also group unrelated transfers into one wakeup occurrence, such as a BLE transfer at the same time that Location entry is satisfied.

Learn how to create your own Programming Language here!!

FranticRock - 16. "Summer of Love" jam

Main iOS Architecture and Patterns

Main iOS Architecture and Patterns

The following design patterns are present in many of apple's iOS frameworks:

1. Target-Action: Can be used to connect a UI control to an implementation of what it does upon being activated by the user.  You can see this pattern in Storyboards when dragging from a control to the code and creating an "Action". Even if your UI classes come from different parents, for example: UIBarButtonItem vs UIButton, they still both use the Target-Action mechanism to handle their pressed events.  The same target-action mechanism is used by gesture recognizers.  A message is also sent along with the action to the target. 


2. Responder-Chain:  Lets your application handle events without knowing which particular object will handle them. An initiator kicks off an action to the first responder.  That responder may or may not respond to it, or forward it on to the next responder. Typical responder chain (Default view hierarchy):  View-->ViewController-->Window-->Applicastion-->AppDelegate. 


3.  Composite: Manipulate a group of objects as a single object.  Example: create two views: A and B.  Add B as a subview to A. Now manipulating A will also operate on B, because B is inside A's composite.  Now also B's nextResponder is A, because that is its super view.  UIDynamicBehavior is another place where the same pattern is found: a child behaviour can be added to your dynamicBehavior.  Now the physics simulation running in the background will manipulate the parent dynamicBehavior object as a composite, affecting all nested behaviors inside (nested tree) as one object. 


4. Delegation: Customize behavior without subclassing the customized object.  For example: UIApplication --> UIApplicationDelegate.   The App Delegate specifies behaviour for various methods of your application.  The app delegate doesn't have to know anything else about the UIApplication.  It only needs to know how to react to 7 application life cycle events.  If you had to override UIApplication instead of receiving it's delegated events, you would have to understand how UIApplication works:  
1. Which methods must you override?
2. Which methods are optional?
3. Do you have to call super on overridden methods?

Other examples of Delegates:
AVAssetResourceLoader --> AVAssetResourceLoaderDelegate
CALayer --> CALayerDelegate
GKSession --> GKSessionDelegate 


5. Data Source: Customize the data retrieval without having to subclass the object that needs the data.  Example:  UITableView --> UITableViewDataSource.  The tableView asks you for things that it needs from the data source, such as: number of rows, number of sections, view for row, etc.  Other examples: 
1. UICollectionView --> UICollectionViewDataSource
2. UIPageViewController --> UIPageViewControllerDataSource
3. UIPickerView --> UIPickerViewDataSource


6. Model-View-Controller:  Build organizational structure around application's responsibilities. The model is your business data definition, and possibly functionality related to that particular entity.  The view is your UI which fires events to perform certain actions.  The controller handles the View's actions, reads models, returns data to Views, and does everything else necessary to allow the View to do its job, and update the models accordingly. 

The below steps are a good general process when building a simple application: 

1. The Human Interface Guideline

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/

Should use this as a guide when designing an application. 

2. Application Definition Statement

Important to come up with a focused application statement.  It's a 30 second elevator pitch of exactly what the application is and who it's for.  For example:  "Allow people to share simple, short updates about what is happening in their lives".  The come up with a list of features that are likely to be used.  In this case:  Networked, Lists of data, Good performance, Add an entry, Add photos, Mark items, Edit posts.  Then figure out what to say No to.   So according to our above application statement, we would drop the following 3:  Add photos, Mark items and Edit posts, because they do not fit into the statement. 

3. Come up with simple wire-frames of all screens. 

This will help visualize layout, content, models and ui controls needed.

4. Define Models

Based on the user story statements, pull out the nouns, and that will likely tell you what models will be used. 

5. Define Views

For example:  Use a tableview. Have table view cells with wrappable text fields and images.  Use UIBarButtonItem to display the + button in the Top right, to create an entry. 

6. Define ViewController

Most likely our View Controller will serve as a data source to our table view.  It will also have actions, such as the "add new entry".  In a simple example, VC also has to manage the networking, such as using NSURLConnection, to retrieve model data, and expose it to the views.  However, ideally we don't want the VC to know anything about the networking layer, and instead use a Query object to retrieve the data.