Tuesday, August 31, 2010
What Do They Believe? 1.4 for iPhone - New Religion Trivia Competition
Blackleaf Software LLC has announced their latest update of “What Do They Believe?” app for iPhone/iPod and iPad users.
The app is an educational support for the people who don't have a clue about any other religion. Containing basic fundamental knowledge of various religions and religious symbols app provides with a bit of education.
These latest version of the app includes a fun and informative trivia game. It’s additional “Which Are You?” section makes users able to participate for their religion in a global trivia game. During the game, users accumulate points for their religion. Scores are tallied from around the world by the What Do They Believe? live ranking system. The three religions with the highest scores are highlighted on the worldwide leaderboard.
What Do They Believe? is an application designed for sharing knowledge.
These are some of the features enjoyed by users in What Do They Believe?
* User friendly, easy to navigate and scroll interface
* Contains basic, important information about a variety of faiths
* Click on religious symbol buttons to read more about the place that symbol has in a religion
* Play on your religion's team in the "Which Are You?" trivia game, enjoyed by players from around the world
* Live ranking system updates scores for each religion in the trivia game (internet connection required) and the top 3 highest scoring religions appear on leaderboard
* This is a fun and informative application!
Device Requirements:
* 3G iPhone and iPod touch, iPad
* Requires iOS 3.0 or later
* 14.1 MB
Pricing and Availability:
What Do They Believe? 1.4 is only $0.99 (USD) and available worldwide exclusively through the App Store in the Education category.
For more information click here
Monday, August 30, 2010
Caring for the earth becomes simple and fun with Green Quest 1.1 on your iPhone/iPad touch
Green Queens and Kings has announced the release of their new app for iPhone, iPad and iPod touch-Green Quest 1.1.
Green Quest is a perfect gameplay for children inculcating the respect for the earth and forming leader skills in each child.
The app makes kids able to name and design their own character. They can be a queen or a king outlining the missions and then going to accomplish them. This missions involve the whole family and step by step they will be supporting the healing and caring of our planet.
In addition to above features the app gets kids outside instead of making them addicted to the play. For this reason a big problem of the parents, worrying that their child spends to much time playing the games, will be solved.
Parents and teachers will want their kids to use Green Quest with friends, neighbors, and in classrooms around the globe. With Green Quest caring for the earth becomes simple and fun.
Green Quest features include:
* Customizable characters
* Interactive storytelling
* Compelling visuals
* Rich graphics
* Available in English or Chinese
* Fun virtual rewards
* The real reward of helping the environment and having fun
Supported Languages:
* US English and Chinese
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.1.3 or later
* 7.2 MB
Pricing and Availability:
Green Quest 1.1 is $.99 (USD) and is available worldwide exclusively through the iTunes app Store in the Games or Green Apps categories.
For more information click here
Green Quest is a perfect gameplay for children inculcating the respect for the earth and forming leader skills in each child.
The app makes kids able to name and design their own character. They can be a queen or a king outlining the missions and then going to accomplish them. This missions involve the whole family and step by step they will be supporting the healing and caring of our planet.
In addition to above features the app gets kids outside instead of making them addicted to the play. For this reason a big problem of the parents, worrying that their child spends to much time playing the games, will be solved.
Parents and teachers will want their kids to use Green Quest with friends, neighbors, and in classrooms around the globe. With Green Quest caring for the earth becomes simple and fun.
Green Quest features include:
* Customizable characters
* Interactive storytelling
* Compelling visuals
* Rich graphics
* Available in English or Chinese
* Fun virtual rewards
* The real reward of helping the environment and having fun
Supported Languages:
* US English and Chinese
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.1.3 or later
* 7.2 MB
Pricing and Availability:
Green Quest 1.1 is $.99 (USD) and is available worldwide exclusively through the iTunes app Store in the Games or Green Apps categories.
For more information click here
Sunday, August 29, 2010
Core Dump
I've decided to create a second blog at http://jeff-lamarche.blogspot.com where I'll put any posts that are not related to writing iOS software, Apple, or the mobile software industry.
My first substantive post should show up some time this evening if all goes well.
My first substantive post should show up some time this evening if all goes well.
Saturday, August 28, 2010
Mea Culpa
The original version of my Briefs.app blog post contained a snarky comment about the Director of the App Review team and a link to a Wired article about his past. A friend of mine, who happens to work at One Infinite Loop, privately took me to task for including that link in my post.
It took me about two seconds, now that I'm a little further away from it and not as angry, to realize that he's 100% right. It was a dick move on my part and I'm sorry for it. I have removed the link and offer my apologies to Phillip Shoemaker. The fact is, I have no visibility into what's going on and don't know where the holdup is on Briefs.app. For all I know, Mr. Shoemaker could be valiantly fighting for Briefs.app against higher up forces in the company, so casting an ad hominem attack like that was juvenile and uncool.
My basic feelings about the matter are unchanged, however. It was uncool when Apple left Google Voice in limbo, but that was one small product from one very large company. In this case, it's the sweat equity from one individual developer who worked very, very hard, sacrificing sleep, family time, and entertainment to create something very cool. The impact is much greater and much more personal and it's hard for me not to get angry about it.
It took me about two seconds, now that I'm a little further away from it and not as angry, to realize that he's 100% right. It was a dick move on my part and I'm sorry for it. I have removed the link and offer my apologies to Phillip Shoemaker. The fact is, I have no visibility into what's going on and don't know where the holdup is on Briefs.app. For all I know, Mr. Shoemaker could be valiantly fighting for Briefs.app against higher up forces in the company, so casting an ad hominem attack like that was juvenile and uncool.
My basic feelings about the matter are unchanged, however. It was uncool when Apple left Google Voice in limbo, but that was one small product from one very large company. In this case, it's the sweat equity from one individual developer who worked very, very hard, sacrificing sleep, family time, and entertainment to create something very cool. The impact is much greater and much more personal and it's hard for me not to get angry about it.
Friday, August 27, 2010
The Language Buddy iPhone app makes remembering Foreign Languages easy
Buddy Bergman the independent developer is announcing the release of Language Buddy 1.0-new app for iPhone/iPod users.
The app makes easy to learn foreign language and is simple to use. You have to enter the word or short phrase in your native language along with a Romanized "sounds like" spelling for another language and you’ll have easy way to reference that word anytime you like.
Besides, Language Buddy includes additional feature that makes you available to assign photos and audio clips. This additional feature is very useful a simply perfect. For example when you’re tasting some exotic dish in a restaurant and want to remember the name of it, you simply take a picture and spell the name of the dish you like. Or/and record the audio how to properly pronounce the name and the app gives you remembered information anywhere and anytime you may need.
Features:
* Create multiple language sets like English-to-Spanish, English-to-Korean, Japanese-to-English, etc.
* Create categories to organize your entries like food, phrases, people, etc.
* Add a picture to represent an entry like foods, objects, people, etc.
* Record an audio clip for your entries so you can hear the pronunciation whenever you want
* Search all entries in each language set
* Edit the Entries/Categories/Language Sets
* Change the background color
* Set the application to always startup a particular language set so you can jump right in making new entries without jumping around from screen to screen (Primarily for iOS 3.x since the app will always run in the background when using IOS4 unless the app was explicitly exited)
Examples of Use:
* You are traveling abroad and want to remember simple everyday words like Hello, Goodbye, Good Afternoon, Thank you, etc.
* You are traveling abroad and learn a new word or phrase that you want to note for easy future reference
* You eat some new foreign food and you want to remember how to pronounce that food the next time you want it
* You meet new people and don't want to forget their name or face, but don't want to add them to your address book
Device Requirements:
* iPhone, iPod touch
* Requires iPhone OS 3.1.3 or later
* 0.6 MB
The Language Buddy 1.0 is free to download. It will let you create 3 Language Sets and create 10 entries per Language Set. You can do an In-App upgrade for $1.99 to unlock unlimited Language Sets and unlimited entries.
For more information click here
The app makes easy to learn foreign language and is simple to use. You have to enter the word or short phrase in your native language along with a Romanized "sounds like" spelling for another language and you’ll have easy way to reference that word anytime you like.
Besides, Language Buddy includes additional feature that makes you available to assign photos and audio clips. This additional feature is very useful a simply perfect. For example when you’re tasting some exotic dish in a restaurant and want to remember the name of it, you simply take a picture and spell the name of the dish you like. Or/and record the audio how to properly pronounce the name and the app gives you remembered information anywhere and anytime you may need.
Features:
* Create multiple language sets like English-to-Spanish, English-to-Korean, Japanese-to-English, etc.
* Create categories to organize your entries like food, phrases, people, etc.
* Add a picture to represent an entry like foods, objects, people, etc.
* Record an audio clip for your entries so you can hear the pronunciation whenever you want
* Search all entries in each language set
* Edit the Entries/Categories/Language Sets
* Change the background color
* Set the application to always startup a particular language set so you can jump right in making new entries without jumping around from screen to screen (Primarily for iOS 3.x since the app will always run in the background when using IOS4 unless the app was explicitly exited)
Examples of Use:
* You are traveling abroad and want to remember simple everyday words like Hello, Goodbye, Good Afternoon, Thank you, etc.
* You are traveling abroad and learn a new word or phrase that you want to note for easy future reference
* You eat some new foreign food and you want to remember how to pronounce that food the next time you want it
* You meet new people and don't want to forget their name or face, but don't want to add them to your address book
Device Requirements:
* iPhone, iPod touch
* Requires iPhone OS 3.1.3 or later
* 0.6 MB
The Language Buddy 1.0 is free to download. It will let you create 3 Language Sets and create 10 entries per Language Set. You can do an In-App upgrade for $1.99 to unlock unlimited Language Sets and unlimited entries.
For more information click here
Thursday, August 26, 2010
Briefs.app
My co-worker and all-around good guy, Rob Rhyne has officially open sourced Briefs.app as of today. After three months of being dicked around by Apple's review team, he's finally given up on getting Briefs.app onto the App Store.
Throughout the ordeal, Rob has taken the whole thing with tremendous grace and has only good things to say about the people involved in the entire process. I hope he'll forgive me for not being quite so gracious.
I'm pissed on his behalf, since he won't be. Make no mistake: This sucks. This is no way to treat anybody, but especially him. Rob has bent over backwards throughout the process to be nice and work within the system and to avoid saying anything negative about the problems he's faced. Rob has kept the discourse on a level I think few of us could manage. He didn't go out and raise a stink the way many developers have when they felt slighted by the App Review team. Rob just calmly and patiently worked within the system trying to make his case and get a product he worked on for months onto the app store… while working a full time job, starting a new business, and being a parent to a toddler. Oh, and his wife works too. Rob's one of the few developers I know who spends more time sitting at a computer than me.
If Apple's review team had just come out and rejected the app, it would have sucked, and it would have been the wrong decision, but it would have been an acceptable situation. The app review team's job is to make tough decisions. Sometimes they're going to make bad decisions, and sometimes they're going to make decisions that we developers are going to disagree with.
But since making decisions is, in fact, their job and they've never actually made a decision about this particular app, it's not an acceptable nor a forgivable situation. Three fucking months Briefs.app has sat in the review queue, and in that time, the app review team has allowed other prototyping applications onto the app store: applications that do the same basic tasks that Briefs.app was created to do. Interface was approved several weeks after Briefs.app was submitted to the App Store. LiveView and Dapp were both updated just yesterday. iMockups was approved about a week ago.
But Briefs still sits in the queue and nobody can be bothered to even say what the exact holdup is or what needs to happen before a decision will get made.
I don't know what reason they could have for dragging it on like this and not making a decision, but it's not right. Apple owes Rob, and all the people who want to use Briefs, an apology.
Throughout the ordeal, Rob has taken the whole thing with tremendous grace and has only good things to say about the people involved in the entire process. I hope he'll forgive me for not being quite so gracious.
I'm pissed on his behalf, since he won't be. Make no mistake: This sucks. This is no way to treat anybody, but especially him. Rob has bent over backwards throughout the process to be nice and work within the system and to avoid saying anything negative about the problems he's faced. Rob has kept the discourse on a level I think few of us could manage. He didn't go out and raise a stink the way many developers have when they felt slighted by the App Review team. Rob just calmly and patiently worked within the system trying to make his case and get a product he worked on for months onto the app store… while working a full time job, starting a new business, and being a parent to a toddler. Oh, and his wife works too. Rob's one of the few developers I know who spends more time sitting at a computer than me.
If Apple's review team had just come out and rejected the app, it would have sucked, and it would have been the wrong decision, but it would have been an acceptable situation. The app review team's job is to make tough decisions. Sometimes they're going to make bad decisions, and sometimes they're going to make decisions that we developers are going to disagree with.
But since making decisions is, in fact, their job and they've never actually made a decision about this particular app, it's not an acceptable nor a forgivable situation. Three fucking months Briefs.app has sat in the review queue, and in that time, the app review team has allowed other prototyping applications onto the app store: applications that do the same basic tasks that Briefs.app was created to do. Interface was approved several weeks after Briefs.app was submitted to the App Store. LiveView and Dapp were both updated just yesterday. iMockups was approved about a week ago.
But Briefs still sits in the queue and nobody can be bothered to even say what the exact holdup is or what needs to happen before a decision will get made.
I don't know what reason they could have for dragging it on like this and not making a decision, but it's not right. Apple owes Rob, and all the people who want to use Briefs, an apology.
Disco Party By Mix.DJ is a perfect app for your iPhone/iPod and iPad touch
Announcing the launch of new iPhone app that will turn your place into a real night club! The app is DigitalDeejay’s latest release, it runs on iPhone iPad and iPod touch devices and is called Disco Party.
Disco Party By Mix.DJ includes over 500 Disco DJ mixes from around the world. Unlimited musing streaming app is perfect for parties and Disco music fans making them available to explore and share DJ mixes via WIFI or 3G everywhere.
You are able to listen for hours, uninterrupted Disco mixes with your iPhone/iPod/iPad touch in your pocket. And wherever you like!
Once the application is installed, you can:
* Listen to over 500 Disco DJ mixes instantly at your fingertips
* Find DJ mixes, artists or particular songs via the search function
* Create your playlist as many times as you want with the "Favorites" feature
* Browse any playlist mix "Track by Track with ease
* Buy your favorite tunes directly through the iTunes
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.0 or later
* 0.3 MB
Pricing and Availability:
Disco Party 2.0 is $1.99 USD and available worldwide exclusively through the App Store in the Music category.
For more information click here
Disco Party By Mix.DJ includes over 500 Disco DJ mixes from around the world. Unlimited musing streaming app is perfect for parties and Disco music fans making them available to explore and share DJ mixes via WIFI or 3G everywhere.
You are able to listen for hours, uninterrupted Disco mixes with your iPhone/iPod/iPad touch in your pocket. And wherever you like!
Once the application is installed, you can:
* Listen to over 500 Disco DJ mixes instantly at your fingertips
* Find DJ mixes, artists or particular songs via the search function
* Create your playlist as many times as you want with the "Favorites" feature
* Browse any playlist mix "Track by Track with ease
* Buy your favorite tunes directly through the iTunes
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.0 or later
* 0.3 MB
Pricing and Availability:
Disco Party 2.0 is $1.99 USD and available worldwide exclusively through the App Store in the Music category.
For more information click here
Voices that Matter Philadelphia
Just wanted to let you know that I will be speaking at the next Voices That Matter iPhone Developer Conference in Philadelphia, PA which runs from October 16 and 17th. I was originally asked to do a talk on 4.0 Multitasking, which I will be doing. I've also recently been asked to give a second talk on OpenGL ES. I've agreed to do that presentation as well, and now I have a few days to decide on the specific topic and audience and to write up the abstract.
I was thinking of doing a "from 1.1 to 2.0" kind of talk, exploring the differences between the fixed and programmable pipeline and trying to explain some of the more daunting concepts of the programmable pipeline. The goal would be to make the jump from 1.1 to 2.0 (which Apple is pushing) less scary.
I'm not sure if that's a topic with broad enough appeal, though. Are you going to VTM? What would you like to see from an OpenGL ES talk?
I was thinking of doing a "from 1.1 to 2.0" kind of talk, exploring the differences between the fixed and programmable pipeline and trying to explain some of the more daunting concepts of the programmable pipeline. The goal would be to make the jump from 1.1 to 2.0 (which Apple is pushing) less scary.
I'm not sure if that's a topic with broad enough appeal, though. Are you going to VTM? What would you like to see from an OpenGL ES talk?
Wednesday, August 25, 2010
Beta Builder
A week or two ago, Jeffrey Sambells had a blog post about using Xcode's Enterprise distribution for ad hoc distribution. It's a great idea that a lot of developers saw had great potential, but it had several manual steps.
Since that post, Hunter Hillegas of Hanchor, LLC and developer of Vegas Mate, has created an application to automate the entire process. The app is called Beta Builder, and it's free. If you do much ad hoc distribution, you should check it out.
Since that post, Hunter Hillegas of Hanchor, LLC and developer of Vegas Mate, has created an application to automate the entire process. The app is called Beta Builder, and it's free. If you do much ad hoc distribution, you should check it out.
Tapic 1.0 is a Rhythm Game to Play with your own iPod Music
Zentertain has launched new app for iPhone and iPod touch users called Tapic 1.0. The app is rhythm game, giving you ability to play with your own iPod music. You don’t have to buy expensive music packs in other rhythm games, just play with the music you like!
How it works:
Firstly you choose a song from your iPod library. If you play for the first time you have to wait a few seconds for Tapic to generate the tap notes. When the generation will be completed you can play with the song you have chosen in both portrait and landscape game modes.
Besides, the app includes different game themes for each game.
Tapic 1.0 offers to the users various game themes, giving different game experiences and a large variety of song choices.
Device Requirements:
* iPhone and iPod touch
* Requires iOS 4.0 or later
* 5.7 MB
Pricing and availability:
Tapic 1.0 is $0.99 USD and is available exclusively in the App Store in the Games-Music and Games-Action and Music category.
For more information click here
How it works:
Firstly you choose a song from your iPod library. If you play for the first time you have to wait a few seconds for Tapic to generate the tap notes. When the generation will be completed you can play with the song you have chosen in both portrait and landscape game modes.
Besides, the app includes different game themes for each game.
Tapic 1.0 offers to the users various game themes, giving different game experiences and a large variety of song choices.
Device Requirements:
* iPhone and iPod touch
* Requires iOS 4.0 or later
* 5.7 MB
Pricing and availability:
Tapic 1.0 is $0.99 USD and is available exclusively in the App Store in the Games-Music and Games-Action and Music category.
For more information click here
App Licensing
For all those people telling me that Google's App Licensing would put a definitive stop to piracy on Android and that Apple should implement something similar, all I can say is: I told you you were wrong and here's proof, and it didn't take even as long as I said it would.
I understand Google has to address piracy because it's a bit of a black eye for the platform. They need third party developers, and a lot of third party developers are gun-shy about developing for a platform with a reputation for rampant piracy. Although the iPhone has its own problems with piracy, it's on a completely different scale. The closed nature of the platform is actually an advantage for third party developers, much the way gaming consoles are. Sure, Apple's protection scheme has been compromised and any App posted to the app store can be pirated easily. But, because only people who Jailbreak their phones can actually install the hacked software, and Jailbreaking a phone can cause problems with future updates from Apple, there's built-in damage control.
It also helps that you can buy App Store apps in every country where you can legally buy an iPhone. On Android, you can only buy apps in 13 countries, meaning people in other countries either have to do without paid apps, or have to pirate. There's built-in incentive in that system for people who might be perfectly willing to pay for an app to go pirate it. Google would get more for their piracy-battling dollar by expanding the paid markets than by implementing more hare-brained licensing schemes that won't ever make a dent in piracy.
I don't envy Tim Bray's task of having to try and reassure Android developers that this crack isn't a problem. Of course it's a problem. It's a problem the media industries have been fighting with since the dawn of digital content. The RIAA, MPAA, and media companies have invested millions, maybe even billions of dollars into various schemes that have failed to make much of a dent in piracy.
For those who think this App Licensing can ever work, you (much like the media industry) fail to grasp the inherent technical flaw with any kind of DRM. With DRM, you have to provide the legal purchaser with the content and with the key to unlock that content. No matter how sophisticated the stuff in-between, no matter how complex the lock, a sufficiently technically knowledgeable person who has the content and the key to unlocking it can find a way to free the content from its protection. On Android, once you've freed the content from its DRM, you can distribute it to anybody because of the ability to sideload applications. So on most Android phones right now, once a single copy of a program has been hacked, it's just as easy to pirate as it was without App Licensing.
With software, finding the balance between making it inconvenient to pirate (because you can't make it impossible) without overly inconveniencing your customers is hard. It's easier on a closed platform. That's not to say there aren't downsides to a closed platform — of course there are — but this is one of the clear advantages for third party developers. Truth be told, you simply can not stop the dedicated pirate, but a closed platform does deter the bulk of the pirates who can be diverted into paying customers by making it inconvenient. Best of all, it does it without affecting the legal purchasers, unlike most DRM.
When it comes down to it, the most effective way to stop piracy is to make it easy and convenient for as many people to buy content legally as is possible and to price it fairly. This is something Google clearly doesn't get, or else you'd be able to buy paid apps everywhere you can buy an Android phone.
I understand Google has to address piracy because it's a bit of a black eye for the platform. They need third party developers, and a lot of third party developers are gun-shy about developing for a platform with a reputation for rampant piracy. Although the iPhone has its own problems with piracy, it's on a completely different scale. The closed nature of the platform is actually an advantage for third party developers, much the way gaming consoles are. Sure, Apple's protection scheme has been compromised and any App posted to the app store can be pirated easily. But, because only people who Jailbreak their phones can actually install the hacked software, and Jailbreaking a phone can cause problems with future updates from Apple, there's built-in damage control.
It also helps that you can buy App Store apps in every country where you can legally buy an iPhone. On Android, you can only buy apps in 13 countries, meaning people in other countries either have to do without paid apps, or have to pirate. There's built-in incentive in that system for people who might be perfectly willing to pay for an app to go pirate it. Google would get more for their piracy-battling dollar by expanding the paid markets than by implementing more hare-brained licensing schemes that won't ever make a dent in piracy.
I don't envy Tim Bray's task of having to try and reassure Android developers that this crack isn't a problem. Of course it's a problem. It's a problem the media industries have been fighting with since the dawn of digital content. The RIAA, MPAA, and media companies have invested millions, maybe even billions of dollars into various schemes that have failed to make much of a dent in piracy.
For those who think this App Licensing can ever work, you (much like the media industry) fail to grasp the inherent technical flaw with any kind of DRM. With DRM, you have to provide the legal purchaser with the content and with the key to unlock that content. No matter how sophisticated the stuff in-between, no matter how complex the lock, a sufficiently technically knowledgeable person who has the content and the key to unlocking it can find a way to free the content from its protection. On Android, once you've freed the content from its DRM, you can distribute it to anybody because of the ability to sideload applications. So on most Android phones right now, once a single copy of a program has been hacked, it's just as easy to pirate as it was without App Licensing.
With software, finding the balance between making it inconvenient to pirate (because you can't make it impossible) without overly inconveniencing your customers is hard. It's easier on a closed platform. That's not to say there aren't downsides to a closed platform — of course there are — but this is one of the clear advantages for third party developers. Truth be told, you simply can not stop the dedicated pirate, but a closed platform does deter the bulk of the pirates who can be diverted into paying customers by making it inconvenient. Best of all, it does it without affecting the legal purchasers, unlike most DRM.
When it comes down to it, the most effective way to stop piracy is to make it easy and convenient for as many people to buy content legally as is possible and to price it fairly. This is something Google clearly doesn't get, or else you'd be able to buy paid apps everywhere you can buy an Android phone.
Tuesday, August 24, 2010
UIImage-Blur
Many moons ago, I wrote convolution kernel for Cocoa. It had convenience class functions to do many different types of filters, including blurring, embossing, outlining, edge detection, horizontal shift, LaPlacian, soften, high pass, etc. Now, this was before Core Image and long before the switch to Intel. I don't remember exactly when I first wrote it, but I'm guessing it was around 2001 or 2002. The method that actually applied the filter to an image used AltiVec if it was available, and if it wasn't, it did a brute force filter on the CPU.
Of course, once the switch to Intel happened, the AltiVec code was no longer was helpful, and then Apple came out with Core Image which includesda convolution kernel and all of the filter settings I had created and more. So, I stopped maintaining the code.
Then, when the iPhone came out and didn't have Accelerate or Core Image, I saw a potential use for the old source code. I had a project early on where I needed to be able to blur an image. So, I blew the dust off the old code. I didn't convert the entire convolution kernel – I didn't want to go through the effort if it wasn't going to work — so I created a blur category on UIImage. And it didn't work.
Pressed for time, I found another solution because I was uncertain the processor on the original iPhone would be able to apply a convolution kernel fast enough for my purposes, but I included the broken code when I released the source code for replicating the Urban Spoon effect. Today, I received an e-mail from a reader who figured out my rather boneheaded mistake. The convolution filter was fine, I just specified the wrong CGImage when specifying my provider while converting the byte data back to a CGImage.
Now, since I wrote that code, Apple has come out with the Accelerate framework for iOS, so it could definitely be made faster. It's unlikely that I will be able to spend the time converting it to use Accelerate unless I need a convolution kernel for my own client work; I've got too much on my plate right now to tackle it. If anyone's interested in doing the full convolution kernel port, you can check out the source code to Crimson FX. It's an old Cocoa project which may not work anymore, but it has, I believe, the last version of the convolution kernel before I gave up maintaining it. It shouldn't be hard to port the entire convolution kernel to iOS in the same manner. Once you get to the underlying byte data, the process is exactly 100% the same (even if byte order is different), and the code to convert to and from the byte data is this UIImage-Blur category.
So, without further ado, I've created a small scaffold project to hold the unaccelerated UIImage-Blur category. Have fun with it and let me know if you use it in anything interesting. If you improve it and would like to share your improvements, let me know, and I'll post it here.
You can find the source code right here. Here's a screenshot of the test scaffold with the original image and after several blurs have been applied. The image is from the Library of Congress Prints and Photographs Collection. Plattsburgh is where I grew up, so this public domain image struck my fancy. I don't know why, but the Army Base was spelled Plattsburg without the ending 'h' even though the city has always been Plattsburgh with the ending 'h'.
Thanks to Anthony Gonsalves for finding my error!
Of course, once the switch to Intel happened, the AltiVec code was no longer was helpful, and then Apple came out with Core Image which includesda convolution kernel and all of the filter settings I had created and more. So, I stopped maintaining the code.
Then, when the iPhone came out and didn't have Accelerate or Core Image, I saw a potential use for the old source code. I had a project early on where I needed to be able to blur an image. So, I blew the dust off the old code. I didn't convert the entire convolution kernel – I didn't want to go through the effort if it wasn't going to work — so I created a blur category on UIImage. And it didn't work.
Pressed for time, I found another solution because I was uncertain the processor on the original iPhone would be able to apply a convolution kernel fast enough for my purposes, but I included the broken code when I released the source code for replicating the Urban Spoon effect. Today, I received an e-mail from a reader who figured out my rather boneheaded mistake. The convolution filter was fine, I just specified the wrong CGImage when specifying my provider while converting the byte data back to a CGImage.
Now, since I wrote that code, Apple has come out with the Accelerate framework for iOS, so it could definitely be made faster. It's unlikely that I will be able to spend the time converting it to use Accelerate unless I need a convolution kernel for my own client work; I've got too much on my plate right now to tackle it. If anyone's interested in doing the full convolution kernel port, you can check out the source code to Crimson FX. It's an old Cocoa project which may not work anymore, but it has, I believe, the last version of the convolution kernel before I gave up maintaining it. It shouldn't be hard to port the entire convolution kernel to iOS in the same manner. Once you get to the underlying byte data, the process is exactly 100% the same (even if byte order is different), and the code to convert to and from the byte data is this UIImage-Blur category.
So, without further ado, I've created a small scaffold project to hold the unaccelerated UIImage-Blur category. Have fun with it and let me know if you use it in anything interesting. If you improve it and would like to share your improvements, let me know, and I'll post it here.
You can find the source code right here. Here's a screenshot of the test scaffold with the original image and after several blurs have been applied. The image is from the Library of Congress Prints and Photographs Collection. Plattsburgh is where I grew up, so this public domain image struck my fancy. I don't know why, but the Army Base was spelled Plattsburg without the ending 'h' even though the city has always been Plattsburgh with the ending 'h'.
Thanks to Anthony Gonsalves for finding my error!
Gangstafy yo'self with iLookGangsta app for your iPhone 4 retina display
New app for iPhone and iPod users is available on the App Store called iLookGangsta 1.2. iLookGangsta has been developed by Riptide Games, creator of several successful iPhone apps as iLookGood and iLookFunny.
With this app you will have a great fun. It offers 20 custom gangsta items and is perfect for bringing out your inner thug! You’re able to mix gangsta items and match them as you like on the picture from your photo library, as well as take a picture directly from the app.
Anyone can go gangsta with iLookGangsta app including your Grandpa and your baby sister.
And the complicated photos can be uploaded on Facebook or send by e-mail to a friend and you’ll have a great fun!
Additionally, iLookGangsta runs on all iOS based devices, as it has been optimized for iPhone 4's retina display and front camera.
Note that, iLookGangsta Free version is ad supported, but for the users who prefer not to avoid ads, iLookGangsta is available for $.99 (USD).
Riptide Games are also developing next iLook App called iArrPirate, avilability of which is planned for Talk Like a Pirate Day.
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.1 or later
* 8.6 MB
Pricing and Availability:
iLookGangsta 1.2 is only $0.99 USD and available worldwide exclusively through the App Store in the Photography category.
For more information click here
With this app you will have a great fun. It offers 20 custom gangsta items and is perfect for bringing out your inner thug! You’re able to mix gangsta items and match them as you like on the picture from your photo library, as well as take a picture directly from the app.
Anyone can go gangsta with iLookGangsta app including your Grandpa and your baby sister.
And the complicated photos can be uploaded on Facebook or send by e-mail to a friend and you’ll have a great fun!
Additionally, iLookGangsta runs on all iOS based devices, as it has been optimized for iPhone 4's retina display and front camera.
Note that, iLookGangsta Free version is ad supported, but for the users who prefer not to avoid ads, iLookGangsta is available for $.99 (USD).
Riptide Games are also developing next iLook App called iArrPirate, avilability of which is planned for Talk Like a Pirate Day.
Device Requirements:
* iPhone, iPod touch, and iPad
* Requires iPhone OS 3.1 or later
* 8.6 MB
Pricing and Availability:
iLookGangsta 1.2 is only $0.99 USD and available worldwide exclusively through the App Store in the Photography category.
For more information click here
Monday, August 23, 2010
RSS reader can be a useful app for commuters
Francois Goldgewicht offers a new RSS Runner app to iPhone users. The app will be most comfortable and useful for commuters who permanently needs to be aware of fresh news. It can’t compete with Google Reader of course but on the other hand app can provide you with all the information without using your Wi-Fi networks.
RSS Runner works just like Instapaper for your RSS feeds. After downloading the latest updates, even in case of leaving the page and Wi-Fi networks, they remain on the same condition, ready to read. The feature is less useful if you’re subscribing to summary feeds, however.
You can add feeds simply by searching for blogs and other content by name or URL and the app will acknowledge the king of the RSS hill by making it easy to import straight from Google Reader.
RSS Runner offers no option to arrange your feeds in the chronological order they were published, instead it offers blog-by-blog updates.
The app is available on App Store for Free! Download Now!
For more information click here
RSS Runner works just like Instapaper for your RSS feeds. After downloading the latest updates, even in case of leaving the page and Wi-Fi networks, they remain on the same condition, ready to read. The feature is less useful if you’re subscribing to summary feeds, however.
You can add feeds simply by searching for blogs and other content by name or URL and the app will acknowledge the king of the RSS hill by making it easy to import straight from Google Reader.
RSS Runner offers no option to arrange your feeds in the chronological order they were published, instead it offers blog-by-blog updates.
The app is available on App Store for Free! Download Now!
For more information click here
Friday, August 20, 2010
Whizzit Candy Blast for your iPhone/iPod touch will be available on August 27
The most entertaining app created specially for the children ages from three to seven has been released today by Fairlady Media. This unique app, making kids to have a super fun runs on iPhone and iPad touch and will be available on the App Store for only $0.99 on August 27.
From the developers of smash-hit Spazzle this is a second game in their popular Whizzit children's series. The gameplay is called Whizzit Candy Blast and includes a simple contest easy to play for your child.
While playing the game children can help Wilton the Weasel fly his candy-craft over a land of lollipops while blasting candies out of the sky. One hundred candies and chocolates will fly across the sky. Just try if your child can blast all of them! At the end of each game, the candies are counted up and a spectacular fireworks display will celebrate your child's score!
Features:
* Fun artwork, music, animations, and visual effects
* Easy, Medium, and Hard settings for different aged children
* Simple controls
* Reinforces counting, number recognition, and understanding of quantities
Device Requirements:
* iPhone or iPod touch OS 3.0 or later
Pricing and Availability:
Whizzit Candy Blast will be priced at $.99 USD and available worldwide exclusively through the App Store in the Family and Kids Games categories.
Thursday, August 19, 2010
Transparent Grouped Tableviews
I ran into a problem today with a transparent grouped table view. On the table view, I set opaque to NO and set the background color to clearColor so that an image behind the table would show through:
I can't show you the actual app I was working on because I'm under NDA, but I've created a sample project that shows the problem using a really ugly background image. Notice the black around the corners of the group sections:
It took me a while to figure out why this was happening, but with a little crowd-source debugging thanks to Twitter, I've narrowed the culprit down. Even though you can clearly see in the first picture that the table view's background color has been set to clearColor in Interface Builder, that setting is either not being respected, or is being changed somewhere. Now, I'm using stock elements here - no custom views at all - so I know I'm not changing it.
My original fix for this was rather involved, but after a process of elimination where I kept commenting out bits of the fix and and seeing what impact it had, I was able to remove all of the code of my fix except for this line of code:
Turns out all the other parts were red herrings leftover from my various attempts to fix the problem. So, if you're having this problem, just manually re-set the table view's background color to clearColor and you should be good.
(and yes, I'm going to file a bug report now)
I can't show you the actual app I was working on because I'm under NDA, but I've created a sample project that shows the problem using a really ugly background image. Notice the black around the corners of the group sections:
It took me a while to figure out why this was happening, but with a little crowd-source debugging thanks to Twitter, I've narrowed the culprit down. Even though you can clearly see in the first picture that the table view's background color has been set to clearColor in Interface Builder, that setting is either not being respected, or is being changed somewhere. Now, I'm using stock elements here - no custom views at all - so I know I'm not changing it.
My original fix for this was rather involved, but after a process of elimination where I kept commenting out bits of the fix and and seeing what impact it had, I was able to remove all of the code of my fix except for this line of code:
- (void)viewDidLoad
{
[super viewDidLoad];
self.tableView.backgroundColor = [UIColor clearColor];
}
Turns out all the other parts were red herrings leftover from my various attempts to fix the problem. So, if you're having this problem, just manually re-set the table view's background color to clearColor and you should be good.
(and yes, I'm going to file a bug report now)
Core Data Starting Data
Yesterday, I tweeted asking for advice about the best way to provide a starter set of data in a Core Data-based application. The app I'm working on had started with just a small set of starter data, so the first time the app was run, I simply pulled in that starter data from a plist in the background and created managed objects based on the contents and all was good. The user never noticed it and the load was complete before they needed to do anything with the data.
Then the data set got quite a bit larger and that solution became too slow. So, I asked the Twitterverse for opinions about the best way to provide a large amount of starting data in a Core Data app. What I was hoping to find out was whether you could include a persistent store in your application bundle and use that instead of creating new persistent store the first time the app was launched.
The answer came back from lots and lots of people that you could, indeed, copy an existing persistent store from your app bundle. You could even create the persistent store using a Mac Cocoa Core Data application as long as it used the same xcdatamodel file as your iPhone app.
Before I go on, I want to thank all the people who responded with suggestions and advice. A special thanks to Dan Pasco from the excellent dev shop Black Pixel who gave very substantive assistance. With the help of the iOS dev community, it took me about 15 minutes to get this running in one of my current apps. Several people have asked for the details over Twitter. 140 characters isn't going to cut it for this, but here's what I did.
First, I created a new Mac / Cocoa project in Xcode. I used the regular Cocoa Application template, making sure to use Core Data. Several people also suggested that you could use a Document-Based Cocoa Application using Core DAta which would allow you to save the persistent store anywhere you wanted. I create the Xcode project in a subfolder of my main project folder and I added the data model file and all the managed object classes from my main project to the new project using project-relative references, making sure NOT to copy the files into the new project folder - I want to use the same files as my original project so any changes made in one are reflected in the other.
If my starting data was changing frequently, I'd probably make this new project a dependency of my main project and add a copy files build phase that would copy the persistent store into the main project's Resources folder, but my data isn't changing very often, so I'm just doing it manually. You definitely can automate the task within Xcode, and I heard from several people who have done so.
In the new Cocoa project, the first thing to do is modify the persistentStoreCoordinator method of the app delegate so it uses a persistent store with the same name as your iOS app. This is the line of code you need to modify:
Make sure you add the .sqlite extension to the filename. By default, the Cocoa Application template uses an XML datastore and no file extension. The filename you enter here is used exactly, so if you want a file extension, you have to specify it.
Since the Cocoa Application project defaults to an XML-based persistent store, you also need to change the Cocoa App's store type to SQLite. That's a few lines later. Look for this line:
Change NSXMLStoreType to NSSQLiteStoreType.
Optionally, you can also change the applicationSupportDirectory method to return a different location if you want to make the persistent store easier to find. By default, it's going to go in
Next, you need to do your data import. This code will inherently be application-specific and will depend on you data model and the data you need to import. Here's a simple pseudo-method for parsing a tab-delimited text file to give an idea what this might look like. This method creates an NSAutoreleasePool and a context so it can be launched in a thread if you desire. You can also call it directly - it won't hurt anything.
You can add the delegate method applicationDidFinishLaunching: to your app delegate and put your code there. You don't even really need to worry about how long it takes - there's no watchdog process on the Mac that kills your app if it isn't responding to events after a period of time. If you prefer, you can have your data import functionality working in the background, though since the app does nothing else, there's no real benefit except the fact that it's the "right" way to code an application.
Now, run your app. When it's done importing, you can just copy the persistent store file into your iOS app's Xcode project in the Resources group. When you build your app, this file will automatically get copied into your application's bundle. Now, you just need to modify the app delegate of your iOS application to use this persistent store instead of creating a new, empty persistent store the first time the app is run.
To do that, you simply check for the existence of the persistent store in your application's /Documents folder, and if it's not there, you copy it from the application bundle to the the /Documents folder before creating the persistent store. In the app delegate, the persistentStoreCoordinator method should look something like this:
Et voilà ! If you run the app for the first time on a device, or run it on the simulator after resetting content and settings, you should start with the data that was loaded in your Cocoa application.
Then the data set got quite a bit larger and that solution became too slow. So, I asked the Twitterverse for opinions about the best way to provide a large amount of starting data in a Core Data app. What I was hoping to find out was whether you could include a persistent store in your application bundle and use that instead of creating new persistent store the first time the app was launched.
The answer came back from lots and lots of people that you could, indeed, copy an existing persistent store from your app bundle. You could even create the persistent store using a Mac Cocoa Core Data application as long as it used the same xcdatamodel file as your iPhone app.
Before I go on, I want to thank all the people who responded with suggestions and advice. A special thanks to Dan Pasco from the excellent dev shop Black Pixel who gave very substantive assistance. With the help of the iOS dev community, it took me about 15 minutes to get this running in one of my current apps. Several people have asked for the details over Twitter. 140 characters isn't going to cut it for this, but here's what I did.
First, I created a new Mac / Cocoa project in Xcode. I used the regular Cocoa Application template, making sure to use Core Data. Several people also suggested that you could use a Document-Based Cocoa Application using Core DAta which would allow you to save the persistent store anywhere you wanted. I create the Xcode project in a subfolder of my main project folder and I added the data model file and all the managed object classes from my main project to the new project using project-relative references, making sure NOT to copy the files into the new project folder - I want to use the same files as my original project so any changes made in one are reflected in the other.
If my starting data was changing frequently, I'd probably make this new project a dependency of my main project and add a copy files build phase that would copy the persistent store into the main project's Resources folder, but my data isn't changing very often, so I'm just doing it manually. You definitely can automate the task within Xcode, and I heard from several people who have done so.
In the new Cocoa project, the first thing to do is modify the persistentStoreCoordinator method of the app delegate so it uses a persistent store with the same name as your iOS app. This is the line of code you need to modify:
NSURL *url = [NSURL fileURLWithPath: [applicationSupportDirectory stringByAppendingPathComponent: @"My_App_Name.sqlite"]];
Make sure you add the .sqlite extension to the filename. By default, the Cocoa Application template uses an XML datastore and no file extension. The filename you enter here is used exactly, so if you want a file extension, you have to specify it.
Since the Cocoa Application project defaults to an XML-based persistent store, you also need to change the Cocoa App's store type to SQLite. That's a few lines later. Look for this line:
if (![persistentStoreCoordinator addPersistentStoreWithType:NSXMLStoreType
configuration:nil
URL:url
options:nil
error:&error]){
Change NSXMLStoreType to NSSQLiteStoreType.
Optionally, you can also change the applicationSupportDirectory method to return a different location if you want to make the persistent store easier to find. By default, it's going to go in
~/Library/Application Support/[Cocoa App Name]/which can be a bit of a drag to navigate to.
Next, you need to do your data import. This code will inherently be application-specific and will depend on you data model and the data you need to import. Here's a simple pseudo-method for parsing a tab-delimited text file to give an idea what this might look like. This method creates an NSAutoreleasePool and a context so it can be launched in a thread if you desire. You can also call it directly - it won't hurt anything.
- (void)loadInitialData
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] init];
[context setPersistentStoreCoordinator:self.persistentStoreCoordinator];
NSString *path = [[NSBundle mainBundle] pathForResource:@"foo" ofType:@"txt"];
char buffer[1000];
FILE* file = fopen([path UTF8String], "r");
while(fgets(buffer, 1000, file) != NULL)
{
NSString* string = [[NSString alloc] initWithUTF8String:buffer];
NSArray *parts = [string componentsSeparatedByString:@"\t"]
MyManagedObjectClass *oneObject = [self methodToCreateObjectFromArray:parts];
[string release];
}
NSLog(@"Done initial load");
fclose(file);
NSError *error;
if (![context save:&error])
NSLog(@"Error saving: %@", error);
[context release];
[pool drain];
}
You can add the delegate method applicationDidFinishLaunching: to your app delegate and put your code there. You don't even really need to worry about how long it takes - there's no watchdog process on the Mac that kills your app if it isn't responding to events after a period of time. If you prefer, you can have your data import functionality working in the background, though since the app does nothing else, there's no real benefit except the fact that it's the "right" way to code an application.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Do import or launch threads to do import
// So, do this:
[self loadInitialData];
// or this:
[self performSelectorInBackground:@selector(loadInitialData) withObject:nil];
// But not both for the same method probably
}
Now, run your app. When it's done importing, you can just copy the persistent store file into your iOS app's Xcode project in the Resources group. When you build your app, this file will automatically get copied into your application's bundle. Now, you just need to modify the app delegate of your iOS application to use this persistent store instead of creating a new, empty persistent store the first time the app is run.
To do that, you simply check for the existence of the persistent store in your application's /Documents folder, and if it's not there, you copy it from the application bundle to the the /Documents folder before creating the persistent store. In the app delegate, the persistentStoreCoordinator method should look something like this:
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator
{
@synchronized (self)
{
if (persistentStoreCoordinator != nil)
return persistentStoreCoordinator;
NSString *defaultStorePath = [[NSBundle bundleForClass:[self class]] pathForResource:@"My_App_Name" ofType:@"sqlite"];
NSString *storePath = [[self applicationDocumentsDirectory] stringByAppendingPathComponent: @"My_App_Name.sqlite"];
NSError *error;
if (![[NSFileManager defaultManager] fileExistsAtPath:storePath])
{
if ([[NSFileManager defaultManager] copyItemAtPath:defaultStorePath toPath:storePath error:&error])
NSLog(@"Copied starting data to %@", storePath);
else
NSLog(@"Error copying default DB to %@ (%@)", storePath, error);
}
NSURL *storeURL = [NSURL fileURLWithPath:storePath];
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption,
[NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, nil];
if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error])
{
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
abort();
}
return persistentStoreCoordinator;
}
}
Et voilà ! If you run the app for the first time on a device, or run it on the simulator after resetting content and settings, you should start with the data that was loaded in your Cocoa application.
Famished Farm Animal Frenzy 1.0 is new App for iPad
5 Minute Games, Inc has released new iPad version of their popular and successful iPhone app Famished Farm Animal Frenzy. Famished Farm Animal Frenzy is a game for up to four players. You gather around your device, choose one from given four different barnyard animals and play from the side your selected animal is. The app offers 3D melons flung around, which you have to get your animal eat more then others do.
The gameplay is similar to traditional board game only playing on a modern device. The App features great folk music, funny sound affects and high quality graphics.
Famished Farm Animal Frenzy is fun for all ages and kids will love this easy-to-use, family friendly app as much as adults.
These are some of the features highlighted in Famished Farm Animal Frenzy
* Fun and exciting game app developed exclusively for the iPad
* Appropriate for all ages
* Up to 4 players can play at one time
* Fast action
* Choice of 4 animals
* Multi-touch controls
* 3D melons roll and bounce around in a chaotic frenzy
* Folk music plays during game
* Funny sound effects
* Gophers sit on sidelines and toss in melons
Device Requirements:
* iPad Compatible
* Requires iOS 3.0 or later
* 10.9 MB
Pricing and Availability:
Famished Farm Animal Frenzy 1.0 is only $0.99 (USD) and available worldwide exclusively through the App Store in the Games category.
For more information click here
The gameplay is similar to traditional board game only playing on a modern device. The App features great folk music, funny sound affects and high quality graphics.
Famished Farm Animal Frenzy is fun for all ages and kids will love this easy-to-use, family friendly app as much as adults.
These are some of the features highlighted in Famished Farm Animal Frenzy
* Fun and exciting game app developed exclusively for the iPad
* Appropriate for all ages
* Up to 4 players can play at one time
* Fast action
* Choice of 4 animals
* Multi-touch controls
* 3D melons roll and bounce around in a chaotic frenzy
* Folk music plays during game
* Funny sound effects
* Gophers sit on sidelines and toss in melons
Device Requirements:
* iPad Compatible
* Requires iOS 3.0 or later
* 10.9 MB
Pricing and Availability:
Famished Farm Animal Frenzy 1.0 is only $0.99 (USD) and available worldwide exclusively through the App Store in the Games category.
For more information click here
Wednesday, August 18, 2010
The Funny Thing About Old Code…
The funny thing about old code, and most new code, is that there's usually room for improvement. Shortly after posting NSString appendToFile:usingEncoding:, I realized I could've kill two birds with one stone by adding a category method on NSData and then calling that method from the NSString category method. That way I'd get the functionality on both classes without repeating logic.
Without further ado:
Without further ado:
#import <Foundation/Foundation.h>
@interface NSData(MCFileAppend)
- (BOOL)appendToFile:(NSString *)path;
@end
@implementation NSData(MCFileAppend)
- (BOOL)appendToFile:(NSString *)path
{
NSFileHandle *fh = [NSFileHandle fileHandleForWritingAtPath:path];
if (fh == nil)
return [self writeToFile:path atomically:YES];
[fh truncateFileAtOffset:[fh seekToEndOfFile]];
[fh writeData:self];
[fh closeFile];
return YES;
}
@end
#pragma mark -
@interface NSString(MCFileAppend)
- (BOOL)appendToFile:(NSString *)path usingEncoding:(NSStringEncoding)encoding;
@end
@implementation NSString(MCFileAppend)
- (BOOL)appendToFile:(NSString *)path usingEncoding:(NSStringEncoding)encoding
{
NSData *encoded = [self dataUsingEncoding:encoding];
return [encoded appendToFile:path];
}
@end
Subscribe to:
Posts (Atom)