Dapp

We have had two separate bug reports about a rare instance of users not being able to permanently create new objects in their pages.  Unfortunately, we are unable to reproduce this bug.  Even when testing with the same iPhone version and OS.

This is most likely due to some issue when inserting these objects into the database.

The next version of Dapp will include more robust error reporting features that will inform us of any database errors.  Hopefully, through this we can track down the cause of this issue.

Please contact us at dapp@kerofrog.com.au if you are getting any errors so that we can address them as quickly as possible.

Update: This was an issue with non-english international settings. This has been addressed in an update currently in review with Apple.

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.

Specifically, the available actions will be:

• Push: By selecting this option, you will then be able to link up your object to another Dapp page.  In the code itself, a user pressing on your object will cause the linked page to be shown.
• Pop: A user pressing this object will cause the current page to slide-out, showing the previous view controller on the stack.  Basically, this is the same as when you press on the ‘top-left’ arrow back button in a standard iPhone application.
• Alert View: You will be able to customise the look of an alert view that will be displayed when the user touches your object. Anything from a simple message to presenting the user with a selection of options.
• Action Sheet: An action sheet will slide up when the user selects your object.  You are able to customise the title and buttons that are displayed to the user.

This is very exciting news and being able to see this code in it’s raw form should prove to be very educational for learning iPhone developers.

We are on target to submit this to the App store for review on Wednesday the 26th of May.

Action Sheet Example

Alert View Example

Dapp HD will be an iPad version of Dapp.  Specifically, it will be targeted at quickly developing iPad mockups and exporting them to PDF and code.

Mid June is a fairly aggressive target, so we will keep you updated on our progress.

Right now we are working directly with the iPad simulator, with the iPad currently on Pre-Order.  We ordered through the developer portal, so fingers crossed that Apple gives us preference and that we can receive one on the release date of May 28.

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.