Dapp

This update addresses issues users have been having running Dapp on pre-release iPhone OS Versions.

What else is new in Version 1.0.1

• View controllers will now have their background property set correctly when exporting to code
• Fixed bug when trying to export a design with no pages

Thought some developers might like to know how I solved this problem.  Our particular scenario is as follows:

1. Installed Xcode 3.2.3 OS 4.0 Beta 4 over the top of Xcode 3.2.2 (mistake)
2. Reinstalled Xcode 3.2.2 over the top of Xcode 3.2.3 OS 4.0 Beta 4
3. Installed Xcode 3.2.3 OS 4.0 Beta 4 in a seperate directory
4. Opened Dapp project using Xcode 3.2.3 Beta to fix bug (mistake)
5. Opened project in Xcode 3.2.2 to build for distribution and had constant code-sign errors

Closest way to explain it would be that it seems like by opening and editing/saving/building the project in Xcode 3.2.3, changes were made to the project structure which is what caused the code-sign errors.  This could have been avoided if i had just copied the project and worked in Xcode 3.2.3 using a seperate copy.

FIX

1. Create a new project in Xcode 3.2.2
2. Copy over all project code files and resources
3. Link up everything (basically make sure everything is the same as the original)
4. Distribute!  No code-sign error.

Our crack team of testers missed a code export bug where the View Controller background color is not being set. This has been corrected in version 1.0.1 which has been submitted to the app store for review.

Update: The 1.0.1 release has been pulled back to add support for OS 4.0 Beta iPhones and to fix a bug when attempting to export to code a design with no pages.  I really need to let go the tester responsible for letting that slip.

Update 2: Found the issue.   I’ve done testing and Dapp is now stable in OS 4.0.  I’ll be submitting the update as a ‘crash-fix’ to Apple with an urgent priority.

Update 3: Completed and submitted to Apple.  I’ve also requested priority due to OS 4.0 users experiencing crashes.  Had some annoying delays due to code signing issues, feel free to read the next post for details.

The next version of Dapp will have action support. Allowing you to setup objects to react to user events, such as a button being pressed or a tableview row being selected. A full summary of the 1.0.2 release shall be posted in the next few days.

During this time, feel free to contact us with what you would like to see in Dapp. We are here to provide a service to the developer community, and all feedback is appreciated.

Here at kerofrog we find user interface design to be critical. Ideally, we love to create designs that do not require you reading a manual to work out how to do anything.

Unfortunately there is one area of Dapp that stands out as requiring instructions on it’s use. Specifically, the Navigation Controller option in the Page Options screen.

First, perhaps we can explain what this option does.

When we export the code, we create a View connected to a View Controller which is connected to a Navigation Controller.

[Navigation Controller] -> [View Controller] -> [View]

The problem with a Navigation Controller is that it automatically inserts a Navigation Bar on each of your screens.  This Navigation Controller will push down all of the objects you have created in Dapp.  I am sure that after a few uses of Dapp, you will see how your nicely organised screen with your own Navigation Bar and other objects has now been pushed down, with two navigation bars sitting at the top of the screen.  As can be seen in the next screenshot.

Doesn’t look very pretty, does it?

That top blank bar is the Navigation Bar that the Navigation Controller automatically created.  The solution is to go into the code and manually move our objects up by 44 pixels.  Which is time consuming and annoying.  Luckily, by switching on the Navigation Controller option in our Page Options screen, Dapp will automatically move all of our objects back up by the required 44 pixels.  The side-affect is that the Navigation Bar you created will be hidden behind the Navigation Controller.

Luckily, this isn’t so bad, as any settings you applied to the Navigation Bar you created can be transferred over to apply to the Navigation Controller.  This does require writing code, but as you have your own Navigation Bar created in the code, you can just look at the code to see what settings you need to apply to the Navigation Controller.

Of course, wouldn’t it be nice if Dapp just did this for us? The good news is that in a future update, Dapp will do this for you, by checking whether you have created a Navigation Bar and automatically copying over these settings to the Navigation Controller for you.

Phew, that took a while to explain. Almost forgotten the original reason for this post.  Which happens to be User Interface Design and an option in Dapp that requires a manual.  ;)

We will be creating a separate screen for our Export to Code option in the future, one where you have more control on how the mockups are exported.  It will (hopefully) make perfect sense.

Example

To do this yourself in code, you will need to open up the ViewController for the navigation bar that you wish to edit. In the init method, you can use the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

(id)init {
	if (self = [super init]) {
                /*** Dapp Generated Code ***/
		// Change this to set your own title for the view controller
		self.title = @"My Title";
 
		// Link this view controller to our Dapp generated view
		UIView *dappFeedView = [[DappFeedView alloc] initWithParentViewController:self];
		self.view = dappFeedView;
 
		// The view controller now has it's own copy of our Dapp view, we can release our copy
		[dappFeedView release];
 
                /*** Custom code that we can add to update the navigation bar ***/
		UIBarButtonItem *infoButtonItem = [[UIBarButtonItem alloc] initWithTitle:@"Info" // The title
							 style:UIBarButtonItemStyleBordered  // The style of the button item
							 target:self // Target (where we will handle this button being pressed)
							action:@selector(infoButtonAction)]; // The method to handle the button press
		[self.navigationItem setRightBarButtonItem:infoButtonItem];  // We set this button to be the right bar button
		// The navigation item has a copy of this bar button item, release our copy
		[infoButtonItem release];
 
	}
	return self;
}
 
// Our button item action method
- (void)infoButtonAction {
	NSLog(@"User has pressed the info button, do something");
}

There are a few more other things you can do with a Navigation Controller’s Navigation Bar, but these do become increasingly complex and it is generally not a good UI practice to clutter your navigation bar with objects.

As mentioned previously, this is a TODO for something that will be automated for you in future versions of Dapp.

We have had a few questions about how the code generation capabilities in Dapp work. I thought I would write a post answering some of the more common questions, however. If you just want to visually see how it works, then watch our Hello World tutorial.

Will Dapp be affected by the new clause in the iPhone developer agreement (clause 3.3.1) which states that iPhone apps can not be written on third-party platforms, and then subsequently converted into native iPhone code.

Clause 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Dapp has originally been written in Objective-C and is not affected by this clause.

How are these mockups converted into code?

The collection of mockup pages is converted into a group of code files, then compressed along with any images that the user has implemented within Dapp. Once compressed, Dapp opens up the default iPhone mail browser and attaches the compressed file. The user then just has to press send and the file is emailed to their predefined email address.

Can I reuse the code created by Dapp in my own projects?

Certainly. You may reuse the code for any personal or commercial purposes. All we ask is that if you redistribute the code in it’s original form that you do not remove or change the disclaimer.

I have just started to learn how to code my own iPhone apps, what do I have to do to get an iPhone app prototype up and running?

Nearly everything is provided for you. You just need to start a new project in Xcode then delete three files that were automatically created as part of the Xcode project. Drag and drop the files you uncompressed from the zip file provided by Dapp into your Xcode project and that’s it.  You can then press ‘Build & Run’ to run your iPhone app prototype. Our Hello World video tutorial will show you the process.

Naturally, experienced developers can simply drag and drop whichever individual files they require.

Cliff.

Hello World!

I don’t think this type of tutorial needs an introduction. But, we are going to do it with Dapp! The following video will take us through the process… enjoy.

Note: Using Xcode 4? Then please view the Xcode 4 version of this video tutorial – Hello World Tutorial with Xcode 4

Note: Please ensure you select ‘iPhone’ as the Product option when creating a new project in Xcode.  The other two options, Universal and iPad will present a different folder structure to you.

Oh, and before i forget.. here are the project files.

Project Files – Hello World iPhone SDK Tutorial with Dapp

Till next time,
Cliff

Welcome to episode 2 of Creating on iPhone app with Dapp. I will be showing you how to build an iPhone app from scratch. At the end of these tutorials we will be submitting and releasing our funky new app on the app store.

In our last tutorial, we defined some requirements and created our mockups, which were then published to PDF. In this tutorial, we will export our mockups as code, drag and drop the code into a new Xcode project and then finally release a prototype of our app.  The very cool part is we are going to do this with ZERO code… I’m gonna go grab some coffee while you watch the tutorial.  Enjoy!

Note: Please ensure you select ‘iPhone’ as the Product option when creating a new project in Xcode.  The other two options, Universal and iPad will present a different folder structure to you.

Updates:

• File system folders were created in the OS and linked to the Xcode project to further neaten up the code.  This can be seen in the attached zipped project files.

Please find attached the exported code files and a copy of the Xcode project.

Bug Tracker Project Files – Episode 2

Bug Tracker Export to Code Files – Episode 2

Our next few tutorials will move away from Dapp … as disappointing as that is, I will be showing you guys how to:

• setup a SQLite database and how to interact with it
• create a layered design, which will be composed of a data layer and a business layer to interact with out database
• we will also be creating classes for our ‘Projects’.  I will explain this further in later tutorials
• Oh.. and the next tutorial will focus on button events and actions, and pushing new view controllers.  This will allow us to jump between our views that we created. Very cool!

Mmm…. the next tutorial will be called ‘Linking our view controllers’.  See you then.

Well, this is exciting.  I will be showing you how to build an iPhone app from scratch.  Using Dapp.  Oh!  And at the end of these tutorials we will be submitting and releasing our funky new app on the app store too.

Unfortunately, I’m not much of a writer (anyone offering free cheap writing courses? seriously…), but, hopefully I can be a better teacher. So… what shall we make?….

Originally, I had planned to build a Movie Catalog but that’s a bit boring and has been done 15 million times before.  However, we want to build something useful so I have decided we will be building an iPhone bug tracker.  Why?  Because I can’t be bothered having another program on my computer for tracking bugs and I’m often out and about testing Dapp and finding the occasional small bug that I’d like to note down.

For our initial release, we are going to build a very simple version of a bug tracker. So, with an exciting working title of ‘Bug Tracker’, our first step is to jot down our requirements.

Bugs will belong to projects, with each project having a collection of bugs. Projects have the following requirements:

1. We must be able to add new projects
2. We must be able to delete projects
3. We must be able to edit projects
4. We must be able to view existing projects
5. Projects must have a title field

Using these as our base requirements, we can move on to the next step and use Dapp to design some of our mockups.  Now, a friend of mine recently asked me ‘what is a mockup?’… so, in answer. A mockup is a design you create that shows what each screen in your app will look like. A mockup also goes a step further, by showing us the different states of a screen.

The following video will show us how to use Dapp to create our first mockups. You will note that the first two pages we create in the video show the same screen – ‘Project List’ with two different states (standard and edit).

Updates:

• Notes were added to every page
• The back button in ‘Edit Project’ and ‘New Project’ was changed to a cancel button
• The done button style in ‘Edit Project’ and ‘New Project’ was changed to ‘done button style’.  Sorry, that’s a bit confusing, but I will explain this in the next episode

Published PDF

At the end of our video tutorial, we exported our project to PDF.  Check it out here.

Bug Tracker Episode 1 PDF Export

Question: But hey, what about convert to code?

We will move on to this in the next video tutorial episode.  It should be fun.