At some point along my iPhone learning curve, I had to recall some basic principles of object oriented programming — like calling a method from one class to another to pass data. For some reason, using MVC, I was trying to store data objects centrally, assuming all classes would have access to that data. This proved harder than one would imagine. When I finally figured out how to access and call methods in between classes, passing data got much easier.
The code below shows how to:
- Create an instance of another class within a class
- Call a method of another class
- Pass a variable to a method of another class
First, you need to include the header of the ‘other’ class whose method you want to call:
Second, you need to create an instance of that ‘other’ class and call the method, passing the parameter (variable) when needed. This assumes the method you are calling in the other class is inside the view. Otherwise, drop the ‘.view’:
Of course, there are other ways to reference the ‘other’ class instance, like adding it as a view using initWithNibName. I’ll take a look at that in a future post.
If you’ve got a better, more efficient way of doing the above, please feel free to comment.
I don’t know where the Fireworks team at Adobe ranks. Given the obvious rabid developer fanfare over Flash, Flex and AIR, the longtime reign of Photoshop and Premiere, and ever hot ColdFusion and LiveCycle, you got to wonder where Fireworks lives in Adobe’s heart. I mean, if they were to do an award show, how long would it take the Fireworks team to walk from the back of the auditorium to accept an award?
I’ve always loved Fireworks. I use it for everything. I use it to design web pages. I use it to design Flash and Flex assets. I even use it to remove red-eye from family photos. At a certain Flash platform evangelist’s birthday party a few years ago, I was proud to shake the hands of some members of the Fireworks team, giving them my long, overdue tribute as the unsung hero of my creative implementations.
And now, Adobe Fireworks has found a new and valuable home inside my iPhone development workflow. That’s right, I’ve been using Fireworks for all my asset creation needs as I march towards completion of my first iPhone game. In fact, the PNG graphics I’ve created for my game may represent some of the best work I’ve ever done in the application.
I know I’m not the only one leveraging Fireworks in this perfect way. It’s got to be a favorite for other iPhone developers too. But for me, having been such a longtime user and fan, I thought I’d give the killer application it’s due.
p.s. Tell your friend Dreamweaver that I love it too.
The news is official out of the Adobe Industry Analyst Summit that multi-touch Flash has been confirmed. This is going to introduce a new era of Flash development, where coders will be targeting specific hardware capabilities to carry out the full experience of their apps. Assuming there will be a minimal audience of developers coding Flash Multi-Touch only apps, I’m curious to know how developers will handle having to code two separate user interfaces in their apps — just to take advantage of Multi-Touch (and potential accelerometer features) — yet keep the app usable to those without it.
In other words, you, the developer, take on the assignment of coding a Multi-Touch-enabled app. That’s awesome — cool for you! Now, you’ve no doubt got a Flash Multi-Touch enabled device in hand (or a very cool simulator, perhaps in Device Central) to test your app against. But wait… what about those users that may download and install your app that don’t have Multi-Touch-enabled devices? Unless there is a way to only distribute Touch Flash apps to Touch-enabled devices, your app will need a second interface (2′face) to accommodate these users. Perhaps you can provision some nifty tab-ordering for them? If it’s a game, what could you do to avoid make the app totally unusable.
Multi-Touch (and accelerometer) will certainly let developers (and target devices) compete with iPhone. Since iPhone and iPod Touch have this universal feature of touch-ability, it’s not an issue. As an iPhone developer, you don’t need to consider the ‘what ifs’ as you will need to with Flash Touch. (The comparable issue on the iPhone side is actually apparent with network-based and location-based apps, where there is much less feature ability/parity between the devices.)
Now, having said all this, I actually have experience building a ‘touch’-enabled Flash mobile app. In fact, many Flash lite developers do. The Flash Lite platform had a flag in it called System.capabilities.hasStylus(), which tells you if the device is touch-responsive. I used this back in March 2007 when coding a mobile maps app (for Yahoo! hack day) (the app won, btw). Without this feature, it was very difficult to scroll the map tiles of my app. I had to depend on user cursor interaction on the device, which was not as sleek and effective as using your styles to drag the tiles around.
Those who have built apps for the Chumby have also already had access, via Flash Platform, to touchscreen and accelerometer features. I wonder how those Chumby apps that target these features have translated to other mobile devices.
It will be an interesting challenge, but I’m sure Adobe and the Flash community will figure out an effective way of handling this. My biggest interest is how it may affect initial adoption. If developers need to charge extra for not adding in multi-touch support, but rather adding in a 2′face alternative, will the advantage of such a feature be fully realized so quickly?
This past weekend while driving around, I was reminded that you can’t easily escape work. Over a 24 hour period, I encountered the following two Adobe/Flash scenes from behind the wheel - both indication that Adobe and Flash Platform are on the up and up:
Apparently, someone has done very well for themselves designing intro animations and coding ActionScript 1.0. Congrats to this 500 series driver, f8-ing their way to the ultimate driving machine.
And while I had heard of a new, mega Adobe office in Waltham, MA, seeing this giant building was a complete surprise. The parking structure seems bigger than the office, but “The Future Home of Adobe” just outside of a Boston is a great sign of growth for the company set to tap on the huge innovation of Boston students. Ironically, this building sits across highway 128/95 from where Microsoft ‘used to be’.
* Author’s note: I’ve been writing pretty intensely on my blog of late, so I wanted to lighten things up a bit today. I’m not usually one to snap photos of work-related stuff from the road. This was fun and I’m going to try and do it more.
Why don’t more technology platforms have published roadmaps? A product roadmap, in this case for a company’s platform offering, would be a detailed list of fixes and new features in upcoming releases/revisions of the platform. In its most comprehensive and impressive form, the roadmap will include future release dates, version numbers and even advanced documentation on method signature and event changes.
The benefits of a published roadmap could be beneficial to both the company and the developer/user community. Yet, it’s a rare thing to see a roadmap of features available for your platform of choice. Here are 5 possible reasons that a company (or engineering team) wouldn’t publish roadmaps:
1. The company doesn’t know or plan releases. Amongst platforms that I would love to view roadmaps of, I really hope and doubt this is the case. How could a company not know what they are working on in terms of new platform features or fixes? I suppose there has to be some out there that wouldn’t publish a roadmap for this reason, but it’s got to be the last possible reason.
2. The company has low confidence in engineering team. Probably and sadly a bit closer to reality, the company may have a tough time keeping to previously released schedules and as a result, has little confidence in its engineering team to deliver on time. There are other factors in the release process such as sufficient resources, timely QA, scope creep and such. Still, to find yourself in this situation is not good.
3. Admission of guilt. If you publish a list of ‘bugs to be fixed’ too soon, it may show how many flaws there really are in an existing release and force your users/community to lose confidence in the current (and possibly future) release of the platform.
4. The company fears competition will steal their thunder. I’d like to think this is the most frequent reason you don’t release a roadmap. Should you announce your plans to early, via a published roadmap, of ground-breaking new features, you may open the door for your competition to take on those tasks as well. Keeping new features close to your vest can prevent this.
5. Avoid hesitancy of adoption. If the roadmap were to reveal new features or easier/improved ways of doing things, the community may hold off adoption awaiting the better release thus slowing adoption and growth of community.
Again, I think even with these reasons/excuses, companies should make every effort to publish their platform roadmaps. Your users are vital and likely high spirited about your product offering. Keep them in the loop about your upcoming releases, solicit feedback when possible and give them a chance to tell you what should be fixed/improved/added in your next release.
Do you know of any good platform roadmaps out there? Ask your platform company of choice why they don’t publish their roadmaps.
As a platform user and evangelist, I want to see more!
I was surprised to find out how few samples there were for adding and manipulating images in an iPhone app. Rotating an image seemed to be tricky to figure out, but the code for adding and rotating an image is very simple.
The code below shows how to:
- Create a UIImage with an image file
- Create a UIImageView with the dimensions of the UIImage
- Add the UIImage to the UIImageView using the image property
- Add the UIImage to the View
- Create a CGAffineTransform CGAffineTransformMakeRotation
- Apply the CGAffineTransformMakeRotation to the UIImageView
The referenced “image.png” needs to be dragged into the Resources folder of your project inside Xcode. This action will prompt you to confirm the copying of the file to the project folder.
To make the image continue to rotate, include the latter two transform lines inside a loop, perhaps dependent on the device’s acceleration.
If you’ve got a better, more efficient way of doing the above, please feel free to comment.
While developing my first iPhone game App, I’m finding Interface Builder very easy to use. However, in my coding, I had the need to add a UILabel programatically. Similar to other languages/platforms I’ve worked with, handling font size, color and weight can be a little confusing.
The code below shows how to:
- Create new UILabel
- Set UILabel position (x,y) to center and size
- Set UILabel font alignment, color, font name and size
- Add UILabel to your View
- Populate UILabel with an NSString for text.
I woke up in Flash Professional today and realized that developing with Flex so much the past few years has finally changed the way I code Flash Platform apps. For better or worse, working with the RIA framework known as Flex has changed my approach, practice and sense of virtual space as I develop applications.
I’d say that over my 10+ year career coding Flash Platform apps, experiences, intros and animations, I’ve still spent more aggregate time in the Flash IDE environment. On stage, presenting at conferences, I have proclaimed that I am a Flash Platform switch hitter, comfortable in building apps from both sides of the Flash Platform plate. Yet the phase of my career where I’ve really grown as a developer, mostly when I was migrating from AS to AS2, and subsequently from AS2 to AS3, has been spent working with Flex.
As recently as 4 years ago (I know, that’s like 14 in technology years), I was approaching applications much differently. I’d start with layout, color, interaction, transitions, sound and all the other “cool” and “flashy” elements that made rich internet applications rich — before they were actually rich. Code came last, if at all. And there was a time where many of the projects I worked on had minimal code because working with timelines and stage-created symbols came so naturally to me.
Now, I’m completely reversed. Flipped around. A new kind of developer. My approach starts with framework, structure and logic. I think about what classes I’ll need, what approach I’ll take (MVC? Frameworks?), and what 3rd party libraries or components I need to include. And when the app is finally coded, I look at the skeleton of an interface my UI control/component-dependent approach has given me and pray there’s a good designer waiting (or even a simple, snap-in theme waiting for me on scalenine.com).
So now, back in Flash Pro for a bit, I am totally ignoring the stage. I’m avoiding doing much in the software all together, other than dragging some staple UI controls from the components panel to my Library. I jump into FlashDevelop or FlashBuilder (which I still call FlexBuilder) and write ActionScript there. When I’m ready to see my work, I say a prayer and compile, confident it will work well, but hoping it will look decent enough.
Back in the day, I would have known quite well what my app would look like before I coded it. That’s far from reality now. So is this the way I really want to be building apps? Has it made me a more seasoned and valuable developer? Probably, but it really depends on the project at hand. Has this improved performance, size, efficiency, scalability of my apps? Again, it really depends on the project at hand.
So, in conclusion, this doesn’t really matter in the grand scheme. As technology, the industry and demands have evolved, so have I. And don’t get me wrong. If you’re still perfectly comfortable and successful working in Flash Pro, that’s just as good. Developers like me need you now more than ever.
I’ll be making my Flash on the Beach debut this year in Brighton, UK on Sept 20-23. I just finalized my session and description (below). This will be my first time abroad/overseas in 11 years. I am very excited to make the the trip and speak to a different audience.
Tickets are still available but are guaranteed to sell out a few weeks before the event, as history indicates.
The session I’m giving is a bit updated and more intense than the one I gave at FITC just a few months ago. I’m going to dive a bit deeper into my examples (of which I had a lot of help with) and churn out some fresh takes on working with the Flash Microphone. It will be great to see you there.
Flash’s microphone access, while still limited, does provide a unique way of letting our user’s interact with the applications we build and each other.
Chuck will show some exciting implementations of Flash Microphone, ranging from simple visual animations based on the Microphone’s activityLevel, to highly interactive service integrations for recording voice and sound, playing it back and streaming it.
Learn basics of microphone access and see demonstrations of popular open source Flash libraries like Merapi, Red5 and Papervision as they compliment many ways to visualize voice.
If you have a project or special technique to share, please visit getmicrophone.com.
I am an Apple hold out no longer. After decades of resisting and even withstanding years of adoption peer pressure working/living in neighboring towns of Cupertino, I have jumped on the bandwagon. I bought my wife a gen2 iPod Touch, paid $99 to test apps, downloaded/installed the SDK, started playing with examples and have begun to tear into “Beginning iPhone Development” a.k.a. the grapefruit book (among other references).
As I initially cracked open the macbook pro (on loan) and started up xcode for the first time, the years of excuses for holding out so long rushed into my head — immediately countered by all the reasons I’m finally IN. If you’re an able and talented developer that thrives on the (potential of) mass adoption of your work/applications, you may be able to relate to the following:
My excuses for holding out so long:
1. Long and bad history working with Macs. From day 1, 20+ years ago, and especially when I was working tech support at BU getting students online in the mid 90’s, PC’s were always easier to work with, install software and customize.
2. My interest in products, especially mobile and other gadgets, is very much need driven. Having been a Windows Mobile device user for 5 years now, I already enjoyed touchscreen, wifi, excellent web browser ability, installed flash player, mp3 playback and many smart phone features. The Apple devices just didn’t seem to offer much more to me — if anything, a little less.
3. Recognizing that Apple’s initial marketing play on the iPhone was as an advanced iTunes player didn’t interest me as I am not an iTunes customer. I recognize now the brilliance in Apple positioning their device this way towards getting it mainstream adoption.
4. Apple always seemed very “closed” to me. They control everything about their products, and while I recognized it’s the ultimate effort in quality control, it carries with it this imposing and unwelcoming vibe to an innovator like me. This factor also contributes to them not including Flash player on their device, a move that would have had me interested much sooner.
So, having listed my excuses, here are the reasons I’m no longer holding out:
1. My dad has an iPhone (and so does his wife, as well as my father-in-law, so many of my friends and other very influential colleagues). The iPhone is generating so much buzz around me, it’s become too hard to ignore.
2. They are selling iPhones and iPods in Walmart. When I saw this, it really dawned on me how mainstream the product has become. Walmart = the ultimate in mainstream adoption and distribution. It means folks across the country, in all remote, un-tech locations, are buying this device — and more significantly, buying apps to load on to it.
3. My friends are building very cool things on it — and they’re having fun doing it. It seems iPhone development has lit a spark for mobile development, something I was hoping Flash Lite would do for many years. [As a career Flash developer, Flash Lite was a natural transition for me to mobile, and something a dabbled in. Like I said, if iPhone had Flash player, I'd be into both a lot more by now.] These same friends are also blogging and talking about their experiences, which is very encouraging.
4. Coding functionality like location, movement (acceleration) and touch proved to be the ultimate enticing factor. Having developed with one primary language for so long, access to new features lured me to test my abilities as a programmer by grasping another platform/language. It was time to challenge myself where the rewards could be so much more than just adding new tools (skills) to the shed.
So, I’m deep into it now. I’ve already explored so much functionality and am having a lot of fun. As usual, with any activity not involving your “day job”, identifying your own spare time can be just as much a challenge.
Thankfully, my wife has been very supportive, as usual, of me sacrificing TV-couch time with her as I pound out new and un-explored code. After all, as an iPod Touch owner, she’ll be my first and most enthusiastic customer!
Oh, and just to show I’m not totally overcome with the thought that the iPhone is the end-all be-all of mobile devices, enjoy this video…