My new MacBook (and iOS programming)

[billybob476]

I actually wasn't planning to document the process but this i actually kind of fun. I'll roll onto the next chapter (Objective-C) either later on today or tomorrow morning. The goal of the chapter is to make a small console application that will be used in a later chapter and to further familiarize with Objective-C syntax.

Luckily my C programming isn't as rusty as I thought it was! Last time I really used it was in university.

[billybob476]

Made some more progress this morning, worked through chapter 2 of the book which did a quick overview of the Objective-C programming language. Objective C does differ from C++ (that I learned in school) and C# (that I've used from time to time in my still short career). Syntax, naming conventions and core libraries are all a little bit different then I've used before so this was a good way to get into it a bit more.

I was tasked to create a small class. Very basically, a class is a way to represent a "thing" in a program. I created one called "Possession" which represents items a person might own. I gave it various properties such as a name, a serial number and a monetary value. I played with instance methods and class methods (which I knew as 'static' instead of 'class' from C#), how the XCode debugger works and a whole bunch of other details.

Next chapter involves memory management, something I don't have to worry about a whole lot in my web projects, so it should be insightful.

[Feathers]

Sounds fun.

I used to code around a bit for my old PalmOS handhelds but will probably never get to touch iOS which is a bit I'd a shame really.

Keep sharing your progress. It's fun (is that sad? ;)).

[billybob476]

Grrr...no time tonight to run through another chapter, I guess it'll have to wait until tomorrow.

[billybob476]

Got this email from Apple:

You now have access to iTunes Connect, our exclusive, partner-facing website. You may access iTunes Connect using the link below:

iTunes Connect

Log in using the existing username and password for your Apple Developer account.

With iTunes Connect, you can enter into a Paid Applications agreement, setup and edit information about your application, view sales and trend information, retrieve financial reports (if applicable), and create new user accounts for other people at your company.

If you have any questions regarding your iTunes Connect account please Contact Us.

Best Regards,
The App Store Team

I logged in, this site basically allows you to view and agree to seller contracts for paid app store apps, there's more to it but I haven't gone in farther yet (don't think I want to agree to any contracts without at least a cursory inspection). I'm already 'signed on' to the free iOS app contract, I assume the other ones outline revenue sharing, app restrictions, etc.

[billybob476]

Ran through the Memory Management chapter last night. It's actually pretty interesting, even with all the tech and automation, iOS still uses manual reference counting. Basically this means that as the programmer, you have to specifically indicate which entity owns an object, you have to make sure all your referenced objects are released before destroying a parent object, you have to make sure you release an object from its creator if you are switching ownership, etc, etc.

It's a very flexible system, but if you're not paying attention it's very, very easy to create either:

a) a memory leak (which will eventually cause you to have to restart your device, since even if you force-quit an app, it will have no way to release unreferenced memory)
b) premature deallocation (which will cause the app to crash on an invalid memory reference)

Anyways as I mentioned in the last post, this chapter was good for me. As a web developer, the vast majority of objects i create tend to be auto-cleaned at the end of a web request. I also tend not to have to pay too much attention to items stored in my persistent scopes (though I still do) since the web servers I tend to run apps on have 8-16 gigs of ram.

Memory usage and leaks are defintiely something I'll have to keep a closer eye on as I continue down this road.

[Rico]

Interesting stuff Joe.  Glad you are making progress on this.

[QuadShot]

Ran through the Memory Management chapter last night. It's actually pretty interesting, even with all the tech and automation, iOS still uses manual reference counting. Basically this means that as the programmer, you have to specifically indicate which entity owns an object, you have to make sure all your referenced objects are released before destroying a parent object, you have to make sure you release an object from its creator if you are switching ownership, etc, etc.

It's a very flexible system, but if you're not paying attention it's very, very easy to create either:

a) a memory leak (which will eventually cause you to have to restart your device, since even if you force-quit an app, it will have no way to release unreferenced memory)
b) premature deallocation (which will cause the app to crash on an invalid memory reference)

Anyways as I mentioned in the last post, this chapter was good for me. As a web developer, the vast majority of objects i create tend to be auto-cleaned at the end of a web request. I also tend not to have to pay too much attention to items stored in my persistent scopes (though I still do) since the web servers I tend to run apps on have 8-16 gigs of ram.

Memory usage and leaks are defintiely something I'll have to keep a closer eye on as I continue down this road.

Sure, I know that when I suffer from premature deallocation, my memory crashes all the time :) Sorry, that just sounded like it was ASKING for a bad joke!!

[KingIsaacLinksr]

Ran through the Memory Management chapter last night. It's actually pretty interesting, even with all the tech and automation, iOS still uses manual reference counting. Basically this means that as the programmer, you have to specifically indicate which entity owns an object, you have to make sure all your referenced objects are released before destroying a parent object, you have to make sure you release an object from its creator if you are switching ownership, etc, etc.

It's a very flexible system, but if you're not paying attention it's very, very easy to create either:

a) a memory leak (which will eventually cause you to have to restart your device, since even if you force-quit an app, it will have no way to release unreferenced memory)
b) premature deallocation (which will cause the app to crash on an invalid memory reference)

Anyways as I mentioned in the last post, this chapter was good for me. As a web developer, the vast majority of objects i create tend to be auto-cleaned at the end of a web request. I also tend not to have to pay too much attention to items stored in my persistent scopes (though I still do) since the web servers I tend to run apps on have 8-16 gigs of ram.

Memory usage and leaks are defintiely something I'll have to keep a closer eye on as I continue down this road.

This explains so much about certain companies and the apps they put out.

King

[billybob476]

Sure, I know that when I suffer from premature deallocation, my memory crashes all the time :) Sorry, that just sounded like it was ASKING for a bad joke!!

Don't tell my wife!

[billybob476]

This explains so much about certain companies and the apps they put out.

King

Yup, going through this process is definitely giving me a new appreciation of those really good, really stable apps. In ym day job I work in enterprise environments, with load balancing, redundancy and honestly much more horsepower then I can even take advantage of. While smartphones have come a long, long way in a very short time, you're still working with a much more limited resource pool.

I know these reports may not be for everyone, but I'm glad you guys are getting something out of this, I sure know I am.

[Feathers]

In my software background this was all very easy since any form of dynamic allocation was outlawed as a matter of process (which probably means I'd make a very bad App developer!). I'm a bit surprised it's fully manual but I don't really have a sensible baseline for comparison.

[billybob476]

Been quiet on this front for a little while but I've gone through a few more chapters of basic stuff. I made a small app called WhereAmI which uses the Core Location Services to pop up a map with a GPS location of where the phone currently is and allows you to enter an annotation on the map (basically sticking a pin and giving it a label).

The goal of this exercise was to teach about delegates, protocols and how to link functionality to delegates via protocols. Despite going through the chapter I'm still a little hazy on these concepts. Basically, apps follow a Model-View-Controller architecture. Anything you see on the screen is considered a part of the View layer, anything that handles data in anyway (stores, retrieves, modifies, etc) is part of the Model layer. The thing that connects them together is the Controller layer. This is where the concept of delegates come in. They connect the view components (buttons, GPS input, etc) to the app's background logic.

This is a bigger concept then I can easily put in a single post and I'm still processing it myself (my web apps tend to have the same architecture, MVC is standard. It's just the way iOS goes about it seems confusing to me at the moment).

The next chapter was about handling text entry and customizing the popup keyboard which wa fun. There are a variety of keyboard types, some designed for text typing, others with various symbol buttons (such as @) on the main keyboard.

Finally the last exercise I did was to play around with the UIView class. UIView is the basic view objeoct of an iOS app (consisting of a rectangle). You can create views in two ways, via a drag and drop interface in Xcode (the "easy way") and programmatically via subclassing UIView (the "hard way"). In the previous exercises I had been doing things the easy way, but for very fine-grained control, it's good to know how to do things programatically.

So the challenge here was to programatically create rings of concentric circles. Initially just to fill the screen, then extending outside of the screen. By extending them larger then the screen and some other jiggery and poker you enable panning and zooming. Playing with these C graphics objects reminded me of the OpenGL graphics class I took back in university, fun fun!



So all this wall of text to say things continue to progress despite a week or so of life stopping me from sitting down. The iOS adventure continues!

Next chapter...View Controllers! Good! Some more clarification is needed there :) 

[Feathers]

It still all sounds fun although some of the detail loses me. I guess I'd need to read the textbook for a full picture.

[billybob476]

Yeah I realize as I get farther in this will likely get pretty technical (though I'm sure most people on these forums could do this given the motivation) :) I've found that writing these posts helps me process the info after I've gone through the examples.