Today, I started my first task for the CityTech iPhone application - the preferences pane. Surprisingly, this was a very easy. Here are the first few steps:
1) Open your project in Xcode
2) Create a new File
3) Choose “Resource” from the iPhone section
4) Choose “Settings Bundle”
This creates your settings page and links it to the Settings app on the iPhone. Additionally, the copied Settings.bundle file has some example preferences already included. Click the “Build and Go” button to launch the iPhone emulator. Hit the home button on the emulator and launch the Settings app. Click your app from the list and you are good to go. Exit the iPhone Emulator with command-Q.
To modify your preferences, open the tree for “Preference Items.” Our tree has five items. The first item, of type “Group” groups the following four items together on the preferences page. After that, I just added my four text fields using the + sign on the right side of the table. For each item you can set:
* Type (TextField, Slider, etc)
* Default Value
* Title (the question)
* Keyboard Type
* Secure (for passwords)
* Identifier (how your app will reference this field)
The only thing I had trouble with was moving the items once I added them. Originally I added password at the top and couldn’t figure out how to move it to the bottom. A simple drag of the mouse didn’t help. I ended up deleting the line and adding a new one at the bottom.
For more detailed information, read the “Application Preferences” section in Chapter 9 of Apple’s “iPhone App Programming Guide”
Loose project plan
———————————–
Step one - design app. [done]
Step two - break ground. [done]
Step three - setup backend. [done]
Step four - code app
a) Preferences [done]
b) Web service calls
c) Search
d) Results
e) Viewer
Step five - test app
Step six - package app
Step seven - submit to apple for approval
Over thirty years ago, Kay took a class in hotel / motel management. There she met Barb and they developed an instant friendship. Although Kay left that career path in favor of an MBA, the friendship between Kay and Barb flourished and they continued to regularly socialize.
Fast-forward to 2009. Kay’s daughter Bridget was working for a small corporate communications firm when the economic meltdown surprised the world. As her company collapsed, she eventually got laid-off. In an effort to find another job, Bridget embraced social networking sites like Facebook, Twitter and LinkedIn in her quest for a new and hopefully better job. Kay, offered to search her own network of friends for any leads for Bridget. Bridget reluctantly agreed figuring it couldn’t hurt, but had low expectations.
Kay contacted her long-time friend Barb to ask if her son might know of any job openings. This is where I come in - Barb is my mom. My mom cleverly deduced that since I work with computers, and Bridget worked in marketing for computers as an “Online Media Specialist,” perhaps there would be an opportunity for her at CityTech. Not knowing what an “Online Media Specialist” is, I forwarded her resume to the powers that be at CityTech. One thing lead to another and Bridget was hired as the CityTech Marketing Communications Manager.
The moral of the story: The more things change, the more they stay the same. While it is great to embrace technology, it shouldn’t be at the expense of developing relationships. In this case the last place that Bridget would have expected a good job lead ended up being the best one.
Welcome aboard Bridget. Here’s to the original social network, school!
Last week the iTeam was back in action. One iTeam member, code name George, created the project and setup our screens in Interface Builder(IB). IB is one of the tools included in xCode. IB lets you lay out your screens, navigation and digital assets. When complete, you can then run the app in an iPhone emulator. IB is very useful when writing business applications, because when done, you just generate the stubs, and then plug in your business logic / navigation. Hopefully the rest of the application will be as straight forward as IB.
Next week: Preferences…
Loose project plan
———————————–
Step one - design app. [done]
Step two - break ground. [done]
Step three - setup backend. [done]
Step four - code app
a) Preferences
b) Web service calls
c) Search
Step five - test app
Step six - package app
Step seven - submit to apple for approval
As enterprise Java engineers, the iTeam is accustomed to using a continous integration (CI) server, and writing extensive unit tests. In my current project all code written has to have a corresponding unit test that has 100% code coverage for the unit - anything less will fail the build! The iTeam members do not have experience with Apple application development and, as such, we spent a fair amount of time talking about what kind of build environment we should setup. Since the build environment for iPhone applications requires a Mac, we are limited. All of the iTeam developers are equipped with Mac Book Pros. However, CityTech doesn’t have any extra macs laying around ready to be re-purposed. It’s too bad Apple doesn’t let you run Mac OSX in a virtualized enviroment - that would really help. A group decision was made that a CI server will not be required at this time.
Unit testing is a different story. Unit testing our iPhone application will create a set of functional documentation. This functional documentation will help ease our Objective C learning curve. Although it is unlikely we will set any code coverage rules for this application, it will be good practice for the future.
More soon…
Loose project plan
———————————–
Step one - design app. [done]
Step two - break ground. [started]
Step three - setup backend. [started]
Step four - code app
Step five - test app
Step six - package app
Step seven - submit to apple for approval
After work commitments prevented us from meeting last week, the iTeam was back in action today. Today we designed the front-end navigation of our iPhone application. We have three screens:
I’ll release the intent of the application and name in a future post when we are a little further along.
A primary goal of our application is to make it feel like it belongs on the iPhone - as if Apple wrote it. To do that, we spent a lot of time navigating our iPhones and touches to demonstrate functionality. We logged everything the old fashioned way, with pencil and paper. Since we are all working on this application in our free time, pencil and paper keeps our project informal.
It’s amazing how much you learn from an application just by drawing the user interaction. I’ll try to post our drawings this weekend.
Loose project plan
Stay tuned next week as the iTeam will be setting up the build, directory structure, etc.
Today marks the official first day of my iPhone development journey. A small group of CityTech developers, and I have commited to publishing an iPhone/iPod Touch application in the AppStore. We have creatively named this group, the iTeam. At least once a week, the iTeam will meet to forge ahead with our grande plans.
This weekly blog series will focus on taking a simple idea and making it work on the iPhone. As a hard-core Java engineer, I anticipate plenty of hurdles, notably learning OSX and Objective C. However, the upside of being ahead of the curve for mobile development is too enticing to pass up.
The high-level details:
Stay tuned next week as the iTeam will be setting up the development infrastructure and creating the specs for our application.
I am a Java developer. I’ve been a Java developer since before the 1.0 release of the SDK back in 1995. I used NetBeans since it was called Forte for Java and have been dedicated to Eclipse since the 3.0 release. Java is the primary reason that, since 2000, I’ve been able to spend 90% of my time in a Linux environment.
From a phone perspective, I’ve been a Verizon customer since 1997. I started using the Kyocera 7135 smartphone in 2002. I then upgraded to the Treo 650 in 2004, and most recently to the Treo 700w in 2006. All of those phones have fantastic features, and also significant short-comings. None of them fit all of my needs for a smartphone.
You know the story of the iPhone. It’s elegant. The UI is in a class of its own. The MultiTouch interface is revolutionary. High-speed Internet, 2MB camera, a video iPod, PDA features, and now a GPS unit make the iPhone - “The phone to have.” It does have it’s drawbacks, mainly the lack of cut-and-paste and the poor notes support detailed here.
Could a phone be worth taking such a big leap of faith?
The requirements to develop for the iPhone start with an Intel based Macintosh running Leopard. Since you can’t run Leopard in a VM, there is a substantial start-up cost - a minimum of $500 for a Mac Mini. Additionally, iPhone development is done with Objective C. Lastly, in order to use an iPhone, you need to be on AT&T. I have nothing against AT&T, Macs nor learning Objective C, but that is a lot to invest just for the priviledge to get started.
The most important piece of the puzzle is the AppStore. The AppStore is a blessing and a curse as detailed here. But with six million original iPhones and six million iPhone 3Gs, there are twelve million potential users. This doesn’t include the iPod touches that also can use the AppStore. Software can be deployed without the AppStore using an AdHoc method. This would allow a developer to control the deployment of the software, which would be perfect for business looking to develop in-house applications for the iPhone.
The deciding factor for me was thinking in terms of ones and zeroes. In the AppStore, all software is given an equal opportunity. If a piece of software is sold on the AppStore to 1% of the iPhone users at $5.00, after Apple takes their 30%, the developer would take home $420,000. That’s a good reason to take the leap of faith!
On July 11th, after five hours of waiting in line, I walked out with two 16GB iPhone 3Gs. I love the phone - my wife hates it, but that’s a story for another post. About a week later, I ran off to Best Buy, picked up a MacBook, and then signed up for the Apple iPhone Developer Program.
I’m ready to begin my journey of transforming from a Linux / Java world to a Macintosh / iPhone - Objective C world! Over the course of my posts I’ll discuss the challenges of learning the Mac, Objective C and iPhone development. I’ll also address the differences between Objective C and Java, the differences between the iPhone and the other smartphones I’ve used, and the differences between the Mac and Linux. Lastly, I will compare the functionality offered by the OpenSDK to the functionality available in the official iPhone SDK. All of this will be done while trying to answer my ultimate question: Can the iPhone fit all of my needs?
As any user of the excellent open source software Hyperic HQ knows, there are many great features in Hyperic HQ. However, there are also a few short comings. One of these deficiencies in the software is it’s lack of a way to turn off alerts for scheduled downtime.
With the introduction of Hyperic HQ 3.2.2 a new feature was added called the HQU Plugin Framework. This framework gives developers access to the backend database in a fairly friendly API. Written in Groovy, which is a dynamic language for the Java VM. Built on top of java it really simplifies java development. I am a really big fan of groovy (and grails),but since this article is not about groovy or grails, I’ll point you to a great book on groovy by Scott Davis called Groovy Recipes
To install the Platform Alert Manager Plugin:
Download the platalertman0_2.tgz file to your Hyperic server
Run tar -zxvf platalertman0_2.tgz
mv platalertman <hq_home>/hq-engine/server/default/deploy/hq.ear/hq.war/hqu
To test your Platform Alert Manager Plugin:
cd <hq_home>/hq-engine/server/default/deploy/hq.ear/hq.war/hqu/platalertman/bin
java HypericPlatformAlertManager hyperic-url username password [enable|disable] platform-name
For Example:
java HypericPlatformAlertManager http://localhost:7080 hqadmin hqadmin disable myplatform
if it worked, you will get “result=OK”
To schedule downtime in Hyperic:
Copy the platalertman/bin directory to a platform that you would like to schedule for downtime.
Modify the enable.sh and disable.sh scripts to match the platform name
In the hyperic ui, navigate to the platform and click the "Tools Menu" - "New Platform Service"
Name your service something like "Disable Alerts <platform-name>"
Choose a "Service Type" of "FileServer File"
Click "Configuration Properties"
In the "Path" field, put the fully qualified path to the disable.sh script from step 2
Click the "Control" tab
In the "Quick Control" section, change the "Control Action" to "run"
Click the play button
Verify the result in the "Command Status" field at the top of the page
Schedule your down time by clicking the "New" button in the "Control Action Schedule" section
Select "Run" from the "Control Action" menu
In the "Schedule" section, you can schedule your events to run daily, weekly or monthly.
15. Repeat steps 3-14 to setup the “Enable Alerts <platform-name>”You now have a scheduled window of downtime that you can repeat daily, weekly or monthly. It’s not the perfect solution, but it is fully contained within the Hyperic UI.
The Platform Alert Manager plugin would benefit from a few more features. The future enhancement list includes:
Custom plugin that integrates the control function by passing in the current platform.
Auto add the "Platform Downtime Schedule" plugin to the inventory
Please feel free to leave me comments with any suggestions.
While working with Hyperic (http://www.hyperic.com) I found that to help control the Hyperic alerting, I could write a message to the Windows Event Viewer.
LOG4J (http://logging.apache.org/log4j/1.2/index.html), has a built-in appender called NTEventLogAppender. This makes it very simple.
Here is some source code to get you started:
import org.apache.log4j.BasicConfigurator;
import org.apache.log4j.Logger;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.nt.NTEventLogAppender;
public class WindowsEventLogger {
private static Logger logger = Logger.getLogger(WindowsEventLogger.class);
public static void main(String[] args) {
BasicConfigurator.configure();
NTEventLogAppender eventLogAppender = new NTEventLogAppender();
eventLogAppender.setSource(source);
eventLogAppender.setLayout(new PatternLayout(”%m”));
eventLogAppender.activateOptions();
logger.addAppender(eventLogAppender);
logger.info(”Hello World!”);
}
}
Don’t forget to put the NTEventLogAppender.dll in your JAVA.LIBRARY.PATH. In windows, putting the DLL at the root directory of your class should do the trick.
The NTEventLogAppender.dll is in the root directory of the Log4J download.
Ubuntu finally released the files for the JEOS version of Linux.
More information can be found here in the press release:
http://www.ubuntu.com/news/ubuntu-jeos
The download is here:
http://ftp.heanet.ie/disk1/ubuntu-cdimage/jeos/releases/7.10/release/ubuntu-7.10-jeos-i386.iso