2012-08-15T16:30:16+00:00 Zend_Feed_Writer http://www.binpress.com Binpress contact@binpress.com http://www.binpress.com

2012-08-15T16:30:16+00:00 2012-08-15T16:30:16+00:00 http://www.binpress.com/app/quiz-app-starterkit-iphone-ipad-and-universal-ios-6/1075 Heaven Apps noreply@binpress.com http://www.binpress.comdev/profile/13548 Build a fully featured iOS quiz app - add multiple choice questions with any combination of text, picture, video and true / false questions. Many more configuration options - see description for details.A Quiz App starterkit to build Quiz App with Multiple Choice questions having Text, Picture, Video and True/False types of questions: No programming skills required and easy to configure in 15mins. Admin Tool For creating Quiz Data Version 3.2 Features list ARC Package with Complete source code Can add unlimited categories and each category can have unlimited questions of following types, Multiple choice questions with four options Multiple choice questions having four options with Picture Multiple choice questions having four options with Video True/ False Supports two types of data source formats : Property List (XML) and JSON i.e you can have option to choose any format you wish. Can add Unlimited Categories and Unlimited Questions for each of the category. Each category can have all type of questions [Mentioned above] Supports iOS4.3 to iOS 6.1 support iPhone 5 layout support ready Retina and Non-Retina UI images included Universal App (Single binary can run on both (iPhone/iPad) Can be configured to pull shuffled set of questions from pool of questions. Ex: If you add 1000 questions to a category and set max limit for that category to 50 questions then game play will pull 50 questions out of 1000 Randomize Questions - ON/OFF Randomise Options - ON/OFF Highlight correct answer when answered wrong – ON/OFF High Score table lists all the categories with their high scores Configurable +ve and -ve points for each question Configurable timeout duration for each question Beautiful Graphical representation of timeout timer Can easily change the UI images Fade in / out and sliding animations for attractive Transitions - Featured to configure Animation type Score sharing on social networks Twitter & Facebook Any time Quick Support for your integrations. Any specific requirement will be served as freelancer. Many more features to come ahead. Suggestions are welcome to improve the Quiz Starker Kit Developer License : Package includes Admin Tool for creating your Quiz Data + Quiz App Starterkit Source code + Layered PSDs to create your own custom coloured themes Other Licenses : Include Only Quiz App Starterkit Source Code New in version 3.0 Multiple choice questions with four options Multiple choice questions having four options with Picture or Video. True/False question type Can be configured to pull shuffled set of questions from pool of questions. Ex: If you add 1000 questions to a category and set max limit for that category to 50 questions then game play will pull 50 random questions out of 1000 Highlight correct answer when answered wrong – ON/OFF Universal App supports iOS 4.3 to iOS 6.1 ****Note :** Package Includes ARC supported source code & documentation for configurations. How does it work When a user selects a quiz category, the gameplay screen appears. A question with four options will be displayed, and the user has to pick an answer in the given time. Game also supports a configurable score system - the score can be configured for correct and incorrect answers. After the the quiz ends, user is taken to the final score screen.

2012-06-03T22:27:40+00:00 2012-06-03T22:27:40+00:00 http://www.binpress.com/app/pretty-clock-chrono-for-ios-osx/950 WPTechnology noreply@binpress.com http://www.binpress.comdev/profile/1143 A stylized clock for iOS & OSX apps, similar to clocks on TV stations. It includes a timer and a timed alert.Gorgy Clock is a stylized, customizable clock for iOS & OSX apps, similar to clocks on TV stations. It includes a timer function and a timed alert. How to use : 1) Simply add both LTGorgyStyleChrono.h & LTGorgyStyleChrono.m files into your project 2) Add an UIView (or NSView) on your view, square it with the size of your choice (width must be equal to height) : 3) Set its class to LTGorgyStyleChrono 4) That's all folks, it will now start in Chrono mode, using red as the main color, and gray as the inactive color. Available methods : Personalization: - (void)setColorSecondsForOff:(UIColor *)offColor andOn:(UIColor *)onColor; This will set the colors of the lines drawn every seconds (except those at seconds 0,5,10,15,20...) offColor is used to show "inactive" (or future) seconds, onColor to show "active" (or passed) seconds - (void)setColorSecond5ForOff:(UIColor *)offColor andOn:(UIColor *)onColor; Same as the previous method, this one is used to set only seconds located at second 0,5,10,15,20,25,30,35,40,45,50,55 So every 5 seconds it is possible to have a different color than the other seconds. By default, it is the same color but with an higher alpha value (more transparent) - (void)setColorTime:(UIColor *)color; This color is used to set the text that displays the time - (void)setColorBackground:(UIColor *)color; Set the background color, default is transparent. - (void)setColorClockShadow:(UIColor *)color; You can see a little shadow on the bottom of the clock, you can change its color using this method, or set it to transparent (use [UIColor clearColor] to do that) - (void)setColorWarning:(UIColor *)color; This is the color to be used when the warning system blinks the text-time. - (void)setColorExceededTime:(UIColor *)color; This is the color to be used for the second line of text showing how many time has been passed since the warning zone. - (void)setLineHeightForSeconds:(int)height andForSeconds5:(int)height5; This will define the height of the lines used to draw the clock. "andForSeconds5" means the line drawn every 5 seconds. Running functionalities: - (void)setModeToTime:(BOOL)isTime; if set to YES, it will show the current system time like this : if set to NO, then this is the chrono mode : - (void)start; In chrono mode, will start it... - (void)stop; In chrono mode, will stop it... - (void)reset; In chrono mode, will reset the time to 0:00 - (void)resetAndStart; In chrono mode, will reset the time then start the chrono - (void)warnAfterMinute:(int)minute; In chrono mode, it will blink the current time and add an extra elapsed time if the chrono goes above the specified minutes Tap Events (available on iOS only): - (void)setSingleTapResponderTo:(id)_parent selector:(SEL)_selector; - (void)setDoubleTapResponderTo:(id)_parent selector:(SEL)_selector; - (void)setTripleTapResponderTo:(id)_parent selector:(SEL)_selector; Those methods can be used to set a parent & selector that will receive a callback if the view is touched, double-touched or triple-touched. Here's how : 1) set your view to be able to get this information back. For example, in a double-tap, with an LTGorgyStyleChrono named myClock, the declaration looks like this : [myClock setDoubleTapResponderTo:self selector:@selector(doubleTapMyClock)]; 2) somewhere in your code, just add your returning method declared previously : - (void)doubleTapMyClock { NSLog(@"Clock has been double tapped."); }

2011-12-12T20:21:52+00:00 2011-12-12T20:21:52+00:00 http://www.binpress.com/app/inotify-easy-inapp-notifications/662 Nick Lockwood noreply@binpress.com http://www.binpress.comdev/profile/5681 Easy in-app notification framework. Post lightweight notifications to your users to be displayed on app launch. A great way to cross-promote apps or draw attention to hidden features.iNotify is a simple library that allows you to "push" notifications to users of your iPhone or Mac apps that pop up when they open the app. Unlike Apple's built-in push notifications API, these do not appear when the app isn't running (technically, they are pulled by the app rather than pushed), but they require very little in terms of server-side infrastructure or configuration - you simply place a file on public-facing URL somewhere and update it when needed. The notifications consist of a title, message and optionally a button that sends the user to a URL that can be specified on a per-message basis. These notifications are ideal for cross-promoting your apps, or telling users about features that they may have missed. The notifications can also be used to notify users about new releases, but for this you would be better off using our iVersion library, which was specifically designed for the purpose and provides a more automated approach. iVersion and iNotify can be used in the same project without interference. Note that the documentation in this file focusses predominantly on iPhone, but the iNotify library should work equally well on Mac Cocoa apps.

2011-11-04T13:32:06+00:00 2011-11-04T13:32:06+00:00 http://www.binpress.com/app/irate-prompt-users-to-rate-your-app/616 Nick Lockwood noreply@binpress.com http://www.binpress.comdev/profile/5681 Highly configurable, minimal setup, in-app prompt to rate your application on the app storePurpose iRate is a library to help you promote your iPhone and Mac App Store apps by prompting users to rate the app after using it for a few days. This approach is one of the best ways to get positive app reviews by targeting only regular users (who presumably like the app or they wouldn't keep using it!). Supported OS & SDK Versions Supported build target - iOS 6.0 / Mac OS 10.8 (Xcode 4.5, Apple LLVM compiler 4.1) Earliest supported deployment target - iOS 5.0 / Mac OS 10.7 Earliest compatible deployment target - iOS 4.3 / Mac OS 10.6 NOTE: 'Supported' means that the library has been tested with this version. 'Compatible' means that the library should work on this OS version (i.e. it doesn't rely on any unavailable SDK features) but is no longer being tested for compatibility and may require tweaking or bug fixes to run correctly. ARC Compatibility As of version 1.7, iRate requires ARC. If you wish to use iRate in a non-ARC project, just add the -fobjc-arc compiler flag to the iRate.m class. To do this, go to the Build Phases tab in your target settings, open the Compile Sources group, double-click iRate.m in the list and type -fobjc-arc into the popover. If you wish to convert your whole project to ARC, comment out the #error line in iRate.m, then run the Edit Refactor Convert to Objective-C ARC... tool in Xcode and make sure all files that you wish to use ARC for (including iRate.m) are checked. Thread Safety iRate uses threading internally to avoid blocking the UI, but none of the iRate external interfaces are thread safe and you should not call any methods or set any properties on iRate except from the main thread. Installation To install iRate into your app, drag the iRate.h, .m and .bundle files into your project. You can omit the .bundle if you are not interested in localised text. On iOS you will also need to add the StoreKit framework. iRate typically requires no configuration at all and will simply run automatically, using the application's bundle ID to look the app ID up on the App Store. Note: If you have apps with matching bundle IDs on both the Mac and iOS app stores (even if they use different capitalisation), the lookup mechanism won't work, so you'll need to manually set the appStoreID property, which is a numeric ID that can be found in iTunes Connect after you set up an app. Also, if you are creating a sandboxed Mac app and your app does not request the network access permission then you will need to set the appStoreID because it cannot be retrieved from the iTunes service. If you do wish to customise iRate, the best time to do this is before the app has finished launching. The easiest way to do this is to add the iRate configuration code in your AppDelegate's initialize method, like this: + (void)initialize { //configure iRate [iRate sharedInstance].daysUntilPrompt = 5; [iRate sharedInstance].usesUntilPrompt = 15; } Configuration To configure iRate, there are a number of properties of the iRate class that can alter the behaviour and appearance of iRate. These should be mostly self- explanatory, but they are documented below: @property (nonatomic, assign) NSUInteger appStoreID; This should match the iTunes app ID of your application, which you can get from iTunes connect after setting up your app. This value is not normally necessary and is generally only required if you have the aforementioned conflict between bundle IDs for your Mac and iOS apps, or in the case of Sandboxed Mac apps, if your app does not have network permission because it won't be able to fetch the appStoreID automatically using iTunes services. @property (nonatomic, assign) NSUInteger appStoreGenreID; This is the type of app, used to determine the default text for the rating dialog. This is set automatically by calling an iTunes service, so you shouldn't need to set it manually for most purposes. If you do wish to override this value, setting it to the iRateAppStoreGameGenreID constant will cause iRate to use the "game" version of the rating dialog, and setting it to any other value will use the "app" version of the rating dialog. @property (nonatomic, copy) NSString *appStoreCountry; This is the two-letter country code used to specify which iTunes store to check. It is set automatically from the device locale preferences, so shouldn't need to be changed in most cases. You can override this to point to the US store, or another specific store if you prefer, which may be a good idea if your app is only available in certain countries. @property (nonatomic, copy) NSString *applicationName; This is the name of the app displayed in the iRate alert. It is set automatically from the application's info.plist, but you may wish to override it with a shorter or longer version. @property (nonatomic, copy) NSString *applicationBundleID; This is the application bundle ID, used to retrieve the appStoreID and appStoreGenreID from iTunes. This is set automatically from the app's info.plist, so you shouldn't need to change it except for testing purposes. @property (nonatomic, assign) float daysUntilPrompt; This is the number of days the user must have had the app installed before they are prompted to rate it. The time is measured from the first time the app is launched. This is a floating point value, so it can be used to specify a fractional number of days (e.g. 0.5). The default value is 10 days. @property (nonatomic, assign) NSUInteger usesUntilPrompt; This is the minimum number of times the user must launch the app before they are prompted to rate it. This avoids the scenario where a user runs the app once, doesn't look at it for weeks and then launches it again, only to be immediately prompted to rate it. The minimum use count ensures that only frequent users are prompted. The prompt will appear only after the specified number of days AND uses has been reached. This defaults to 10 events. This defaults to 10 uses. @property (nonatomic, assign) NSUInteger eventsUntilPrompt; For some apps, launches are not a good metric for usage. For example the app might be a daemon that runs constantly, or a game where the user can't write an informed review until they've reached a particular level. In this case you can manually log significant events and have the prompt appear after a predetermined number of these events. Like the usesUntilPrompt setting, the prompt will appear only after the specified number of days AND events, however once the day threshold is reached, the prompt will appear if EITHER the event threshold OR uses threshold is reached. This defaults to 10 events. @property (nonatomic, assign) float usesPerWeekForPrompt; If you are less concerned with the total number of times the app is used, but would prefer to use the frequency of times the app is used, you can use the usesPerWeekForPrompt property to set a minimum threshold for the number of times the user must launch the app per week (on average) for the prompt to be shown. Note that this is the average since the app was installed, so if the user goes for a long period without running the app, it may throw off the average. The default value is zero. @property (nonatomic, assign) float remindPeriod; How long the app should wait before reminding a user to rate after they select the "remind me later" option (measured in days). A value of zero means the app will remind the user next launch. Note that this value supersedes the other criteria, so the app won't prompt for a rating during the reminder period, even if a new version is released in the meantime. This defaults to 1 day. @property (nonatomic, copy) NSString *messageTitle; The title displayed for the rating prompt. If you don't want to display a title then set this to @""; @property (nonatomic, copy) NSString *message; The rating prompt message. This should be polite and courteous, but not too wordy. If you don't want to display a message then set this to @""; @property (nonatomic, copy) NSString *cancelButtonLabel; The button label for the button to dismiss the rating prompt without rating the app. @property (nonatomic, copy) NSString *rateButtonLabel; The button label for the button the user presses if they do want to rate the app. @property (nonatomic, copy) NSString *remindButtonLabel; The button label for the button the user presses if they don't want to rate the app immediately, but do want to be reminded about it in future. Set this to @"" if you don't want to display the remind me button - e.g. if you don't have space on screen. @property (nonatomic, assign) BOOL useAllAvailableLanguages; By default, iRate will use all available languages in the iRate.bundle, even if used in an app that does not support localisation. If you would prefer to restrict iRate to only use the same set of languages that your application already supports, set this property to NO. (Defaults to YES). @property (nonatomic, assign) BOOL disableAlertViewResizing; On iOS, iRate includes some logic to resize the alert view to ensure that your rating message is visible in both portrait and landscape mode, and that it doesn't scroll or become truncated. The code to do this is a rather nasty hack, so if your alert text is very short and/or your app only needs to function in portrait mode on iPhone, you may wish to set this property to YES, which may help make your app more robust against future iOS updates. Try the Resizing Disabled example for a demonstration of the effect. @property (nonatomic, assign) BOOL promptAgainForEachNewVersion; Because iTunes ratings are version-specific, you ideally want users to rate each new version of your app. However, it's debatable whether many users will actually do this, and if you update frequently this may get annoying. Set promptAgainForEachNewVersion to NO, and iRate won't prompt the user again each time they install an update if they've already rated the app. It will still prompt them each new version if they have not rated the app, but you can override this using the iRateShouldShouldPromptForRating delegate method if you wish. @property (nonatomic, assign) BOOL onlyPromptIfLatestVersion; Set this to NO to enabled the rating prompt to be displayed even if the user is not running the latest version of the app. This defaults to YES because that way users won't leave bad reviews due to bugs that you've already fixed, etc. @property (nonatomic, assign) BOOL onlyPromptIfMainWindowIsAvailable; This setting is applicable to Mac OS only. By default, on Mac OS the iRate alert is displayed as sheet on the main window. Some applications do not have a main window, so this approach doesn't work. For such applications, set this property to NO to allow the iRate alert to be displayed as a regular modal window. @property (nonatomic, assign) BOOL displayAppUsingStorekitIfAvailable; By default, if iRate is running on iOS 6 or above then when the user agrees to rate the app, the ratings page will be displayed directly within the app instead of linking to the App Store app. If you don't want that, set this property to NO. @property (nonatomic, assign) BOOL promptAtLaunch; Set this to NO to disable the rating prompt appearing automatically when the application launches or returns from the background. The rating criteria will continue to be tracked, but the prompt will not be displayed automatically while this setting is in effect. You can use this option if you wish to manually control display of the rating prompt. @property (nonatomic, assign) BOOL verboseLogging; This option will cause iRate to send detailed logs to the console about the prompt decision process. If your app is not correctly prompting for a rating when you would expect it to, this will help you figure out why. Verbose logging is enabled by default on debug builds, and disabled on release and deployment builds. @property (nonatomic, assign) BOOL previewMode; If set to YES, iRate will always display the rating prompt on launch, regardless of how long the app has been in use or whether it's the latest version. Use this to proofread your message and check your configuration is correct during testing, but disable it for the final release (defaults to NO). Advanced properties If the default iRate behaviour doesn't meet your requirements, you can implement your own by using the advanced properties, methods and delegate. The properties below let you access internal state and override it: @property (nonatomic, strong) NSURL *ratingsURL; The URL that the app will direct the user to so they can write a rating for the app. This is set to the correct value for the given platform automatically. On iOS 5 and below this takes users directly to the ratings page, but on iOS 6 and Mac OS it takes users to the main app page (if there is a way to directly link to the ratings page on those platforms, I've yet to find it). If you are implementing your own rating prompt, you should probably use the openRatingsPageInAppStore method instead, especially on Mac OS, as the process for opening the Mac app store is more complex than merely opening the URL. @property (nonatomic, strong) NSDate *firstUsed; The first date on which the user launched the current version of the app. This is used to calculate whether the daysUntilPrompt criterion has been met. @property (nonatomic, strong) NSDate *lastReminded; The date on which the user last requested to be reminded of an update. @property (nonatomic, assign) NSUInteger usesCount; The number of times the current version of the app has been used (launched). @property (nonatomic, assign) NSUInteger eventCount; The number of significant application events that have been recorded since the current version was installed. This is incremented by the logEvent method, but can also be manipulated directly. Check out the Events Demo to see how this os used. @property (nonatomic, readonly) float usesPerWeek; The average number of times per week that the current version of the app has been used (launched). @property (nonatomic, assign) BOOL declinedThisVersion; This flag indicates whether the user has declined to rate the current version (YES) or not (NO). @property (nonatomic, assign) BOOL declinedAnyVersion; This flag indicates whether the user has declined to rate any previous version of the app (YES) or not (NO). This is not currently used by the iRate prompting logic, but may be useful for implementing your own rules using the iRateShouldPromptForRating delegate method. @property (nonatomic, assign) BOOL ratedThisVersion; This flag indicates whether the user has already rated the current version (YES) or not (NO). @property (nonatomic, readonly) BOOL ratedAnyVersion; This (readonly) flag indicates whether the user has previously rated any version of the app (YES) or not (NO). @property (nonatomic, assign) id delegate; An object you have supplied that implements the iRateDelegate protocol, documented below. Use this to detect and/or override iRate's default behaviour. This defaults to the App Delegate, so if you are using your App Delegate as your iRate delegate, you don't need to set this property. Methods Besides configuration, iRate has the following methods: - (void)logEvent:(BOOL)deferPrompt; This method can be called from anywhere in your app (after iRate has been configured) and increments the iRate significant event count. When the predefined number of events is reached, the rating prompt will be shown. The optional deferPrompt parameter is used to determine if the prompt will be shown immediately (NO) or if the app will wait until the next launch (YES). - (BOOL)shouldPromptForRating; Returns YES if the prompt criteria have been met, and NO if they have not. You can use this to decide when to display a rating prompt if you have disabled the automatic display at app launch. - (void)promptForRating; This method will immediately trigger the rating prompt without checking that the app store is available, and without calling the iRateShouldShouldPromptForRating delegate method. Note that this method depends on the appStoreID and applicationGenre properties, which are only retrieved after polling the iTunes server, so if you intend to call this method directly, you will need to set these properties yourself beforehand, or use the promptIfNetworkAvailable method instead. - (void)promptIfNetworkAvailable; This method will check if the app store is available, and if it is, it will display the rating prompt to the user. The iRateShouldShouldPromptForRating delegate method will be called before the alert is shown, so you can intercept it. Note that if your app is sandboxed and does not have the network access permission, this method will ignore the network availability status, however in this case you will need to manually set the appStoreID or iRate cannot function. - (void)openRatingsPageInAppStore; This method skips the user alert and opens the application ratings page in the Mac or iPhone app store, or directly within the app, depending on which platform and OS version is running. This method does not perform any checks to verify that the machine has network access or that the app store is available. It also does not call any delegate methods. You should use this method to open the ratings page instead of the ratingsURL property, as the process for launching the app store is more complex than merely opening the URL in many cases. Note that this method depends on the appStoreID which is only retrieved after polling the iTunes server, so if you intend to call this method directly, you will need to set the appStoreID property yourself beforehand. Delegate methods The iRateDelegate protocol provides the following methods that can be used intercept iRate events and override the default behaviour. All methods are optional. - (void)iRateCouldNotConnectToAppStore:(NSError *)error; This method is called if iRate cannot connect to the App Store, usually because the network connection is down. This may also fire if your app does not have access to the network due to Sandbox permissions, in which case you will need to manually set the appStoreID so that iRate can still function. - (void)iRateDidDetectAppUpdate; This method is called if iRate detects that the application has been updated since the last time it was launched. - (BOOL)iRateShouldShouldPromptForRating; This method is called immediately before the rating prompt is displayed to the user. You can use this method to block the standard prompt alert and display the rating prompt in a different way, or bypass it altogether. - (void)iRateUserDidAttemptToRateApp; This is called when the user pressed the rate button in the rating prompt. This is useful if you want to log user interaction with iRate. This method is only called if you are using the standard iRate alert view prompt and will not be called automatically if you provide a custom rating implementation or call the openRatingsPageInAppStore method directly. - (void)iRateUserDidDeclineToRateApp; This is called when the user declines to rate the app. This is useful if you want to log user interaction with iRate. This method is only called if you are using the standard iRate alert view prompt and will not be called automatically if you provide a custom rating implementation. - (void)iRateUserDidRequestReminderToRateApp; This is called when the user asks to be reminded to rate the app. This is useful if you want to log user interaction with iRate. This method is only called if you are using the standard iRate alert view prompt and will not be called automatically if you provide a custom rating implementation. - (BOOL)iRateShouldopenAppStore; This method is called immediately before iRate attempts to open the app store, either via a URL or using the StoreKit in-app product view controller. Return NO if you wish to implement your own ratings page display logic. Localisation The default strings for iRate are already localised for many languages. By default, iRate will use all the localisations in the iRate.bundle even in an app that is not localised, or which is only localised to a subset of the languages that iRate supports. If you would prefer iRate to only use the localisations that are enabled in your application (so that if your app only supports English, French and Spanish, iRate will automatically be localised for those languages, but not for German, even though iRate includes a German language file), set the useAllAvailableLanguages option to NO. It is not recommended that you modify the strings files in the iRate.bundle, as it will complicate updating to newer versions of iRate. The exception to this is if you would like to submit additional languages or improvements or corrections to the localisations in the iRate project on github (which are greatly appreciated). If you want to add an additional language for iRate in your app without submitting them back to the github project, you can add these strings directly to the appropriate Localizable.strings file in your project folder. If you wish to replace some or all of the default iRate strings, the simplest option is to copy just those strings into your own Localizable.strings file and then modify them. iRate will automatically use strings in the main application bundle in preference to the ones in the iRate bundle so you can override any string in this way. If you do not want to use any of the default localisations, you can omit the iRate.bundle altogether. Note that if you only want to support a subset of languages that iRate supports, it is not neccesary to delete the other strings files from iRate.bundle - just set useAllAvailableLanguages to NO, and iRate will only use the languages that your app already supports. The old method of overriding iRate's default strings by using individual setter methods (see below) is still supported, however the recommended approach is now to add those strings to your project's Localizable.strings file, which will be detected automatically by iRate. + (void)initialize { //overriding the default iRate strings [iRate sharedInstance].messageTitle = NSLocalizedString(@"Rate MyApp", @"iRate message title"); [iRate sharedInstance].message = NSLocalizedString(@"If you like MyApp, please take the time, etc", @"iRate message"); [iRate sharedInstance].cancelButtonLabel = NSLocalizedString(@"No, Thanks", @"iRate decline button"); [iRate sharedInstance].remindButtonLabel = NSLocalizedString(@"Remind Me Later", @"iRate remind button"); [iRate sharedInstance].rateButtonLabel = NSLocalizedString(@"Rate It Now", @"iRate accept button"); } Example Projects When you build and run the basic Mac or iPhone example project for the first time, it will show an alert asking you to rate the app. This is because the previewMode option is set. Disable the previewMode option and play with the other settings to see how the app behaves in practice. Advanced Example The advanced example demonstrates how you might implement a completely bespoke iRate interface using the iRateDelegate methods. Automatic prompting is disabled and instead the user can opt to rate the app by pressing the "Rate this app" button. When pressed, the app first checks that the app store is available (it may not be if the computer has no Internet connection or apple.com is down), and then launches the Mac App Store. The example is for Mac OS, but the same thing can be applied on iOS.

2011-11-04T13:09:46+00:00 2011-11-04T13:09:46+00:00 http://www.binpress.com/app/iversion-automatic-update-tracking-for-your-apps/615 Nick Lockwood noreply@binpress.com http://www.binpress.comdev/profile/5681 Automatically check for updates to Mac/iPhone App Store apps from within the app and notify users about the new releasePurpose The Mac and iOS App Store update mechanism is somewhat cumbersome and disconnected from the apps themselves. Users often fail to notice when new versions of an app are released, and if they do notice, the App Store's "download all" option means that users often won't see the release notes for the new versions of each of their apps. Whilst it is not permitted to update an App Store app from within the app itself, there is no reason why an app should not inform the user that the new release is ready, and direct them to the App Store to download the update. And if your app is not on the App Store, either because it's an in-house/enterprise iOS app, or a Mac app delivered to customers outside of the store, you can't use the App Store update mechanism anyway. iVersion is a simple, zero-config class to allow iPhone and Mac App Store apps to automatically check for updates and inform the user about new features. iVersion automatically detects when the new version of an app is released on the App Store and informs the user with a helpful alert that links them directly to the app download page. Or if your app is not on the store, iVersion lets you specify a remote plist file to check for new releases, and a download URL where users can get the latest release. iVersion has an additional function, which is to tell users about important new features when they first run an app after downloading a new version. Supported OS & SDK Versions Supported build target - iOS 6.1 / Mac OS 10.8 (Xcode 4.6, Apple LLVM compiler 4.2) Earliest supported deployment target - iOS 5.0 / Mac OS 10.7 Earliest compatible deployment target - iOS 4.3 / Mac OS 10.6 NOTE: 'Supported' means that the library has been tested with this version. 'Compatible' means that the library should work on this OS version (i.e. it doesn't rely on any unavailable SDK features) but is no longer being tested for compatibility and may require tweaking or bug fixes to run correctly. ARC Compatibility As of version 1.10, iVersion requires ARC. If you wish to use iVersion in a non-ARC project, just add the -fobjc-arc compiler flag to the iVersion.m class. To do this, go to the Build Phases tab in your target settings, open the Compile Sources group, double-click iVersion.m in the list and type -fobjc-arc into the popover. If you wish to convert your whole project to ARC, comment out the #error line in iVersion.m, then run the Edit > Refactor > Convert to Objective-C ARC... tool in Xcode and make sure all files that you wish to use ARC for (including iVersion.m) are checked. Thread Safety iVersion uses threading internally to avoid blocking the UI, but none of the iVersion external interfaces are thread safe and you should not call any methods or set any properties on iVersion except from the main thread. Installation To install iVersion into your app, drag the iVersion.h, .m and .bundle files into your project. You can omit the .bundle if you are not interested in localised copy. On iOS you will also need to add the StoreKit framework. iVersion typically requires no configuration at all and will simply run automatically, using the Application's bundle ID to look it up on the App Store. Note: If you have apps with matching bundle IDs on both the Mac and iOS App Stores (even if they use different capitalisation), the lookup mechanism won't work, so you'll need to set the appStoreID property, which is a numeric ID that can be found in iTunes Connect after you set up an app. This is only applicable to App Store apps. Alternatively (or additionally) you can specify an optional remotely hosted Plist file that will be used for the release notes instead of the ones on iTunes. Even if your app is on the store, there are a few advantages to providing your own release notes plist: You can provide release notes for multiple versions, and if users skip a version they will see the release notes for all the updates they've missed. You can provide more concise release notes, suitable for display on the iPhone screen. You can delay the iVersion update alert until you are ready by not including an entry for the latest release until after the app has gone live. If you do wish to customise iVersion, the best time to do this is before the app has finished launching. The easiest way to do this is to add the iVersion configuration code in your AppDelegate's initialize method, like this: + (void)initialize { //example configuration [iVersion sharedInstance].appStoreID = 355313284; [iVersion sharedInstance].remoteVersionsPlistURL = @"http://example.com/versions.plist"; } The Plist file you specify will need to be hosted on a public-facing web server somewhere. You can optionally also add a Plist file to your app containing the release notes for the current version, and specify its path using the localVersionsPlistPath property. The format for both of these plists is as follows: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>1.0</key> <string>First release</string> <key>1.1</key> <string>NEW: Added new snoodlebar feature FIX: Fixed the bugalloo glitch</string> ... </dict> </plist> The root node of the plist is a dictionary containing one or more items. Each item represents a particular version of your application. The key for each value must be a numerical version number consisting of one or more positive integers separated by decimal points. These should match the values you set for the applicationVersion property of iVersion, which by default is set to the Bundle Version (CFBundleShortVersionString or CFBundleVersion) key in your application's info.plist. Each value should be either a multi-line string or an array of strings, each representing a single bullet point in your release notes. There is no restriction to the format of each release note - the approach in the example above is just a suggestion. You can also omit the release notes if you want and just have an empty <array/>. Plist Tips It is not recommended that you include every single version of your app in the release notes. In practice, if a user updates so infrequently that they miss three or more consecutive versions, you still probably only want to show them the last couple of releases worth of notes, so delete older releases from the file when you update. Do not feel that the release notes have to exactly mirror those in iTunes or the Mac App Store. There is limited space in a modal alert and users won't want to read a lot of text whenever they launch your app, so it's probably best just to list the key new features in your versions plist. The local and remote release notes plists do not have to match. Whilst it may be convenient to make them identical from a maintenance point of view, the local version works better if it is written in a slightly different tone. For example the remote release notes might read: Version 1.1 - Fixed crashing bug - Added shiny new menu graphics - New sound settings Whereas the local one might say: Check out the new sound options in the settings panel. You can access the settings from the home screen There's no point in mentioning the bug fix or new graphics because the user can see this easily enough just by using the app. On the other hand, they might not notice the new sound options, or know how to find them. Also don't always feel you have to include the local release notes file. If there are no features that need drawing attention to in the new release, just omit the file - it won't prevent you adding the remote versions file to prompt users to upgrade, and it won't prevent local release notes in future releases from working correctly. Configuration To configure iVersion, there are a number of properties of the iVersion class that can alter the behaviour and appearance of iVersion. These should be mostly self- explanatory, but they are documented below: @property (nonatomic, assign) NSUInteger appStoreID; This should match the iTunes app ID of your application, which you can get from iTunes connect after setting up your app. This value is not normally necessary and is generally only required if you have the aforementioned conflict between bundle IDs for your Mac and iOS apps. This feature is also only used for remote version updates, so you can ignore this if you do not intend to use that feature. @property (nonatomic, copy) NSString *remoteVersionsPlistURL; This is the URL of the remotely hosted plist that iVersion will check for release notes. You can safely update this file before your new release has been approved by Apple and appeared in the store. Set this value to nil if you want to just use the release notes on iTunes. Do not set it to an invalid URL such as http://example.com because this will waste battery, CPU and bandwidth as the app tries to check the invalid URL each time it launches. If you do not include a particular version in the plist, iVersion will not display an update alert for that version even if it detects a new version in the App Store, unless you set useAppStoreDetailsIfNoPlistEntryFound option to YES. @property (nonatomic, copy) NSString *localVersionsPlistPath; The file name of your local release notes plist used to tell users about new features when they first launch a new update. Set this value to nil if you do not want your app to display release notes for the current version. @property (nonatomic, copy) NSString *applicationVersion; The current version number of the app. This is set automatically from the CFBundleShortVersionString (if available) or CFBundleVersion string in the info.plist and it's probably not a good idea to change it unless you know what you are doing. Note that the version numbers on iTunes and in the remote versions Plist will be compared to this value, not the one in the info.plist. @property (nonatomic, copy) NSString *applicationBundleID; This is the application bundle ID, used to retrieve the latest version and release notes from iTunes. This is set automatically from the app's info.plist, so you shouldn't need to change it except for testing purposes. @property (nonatomic, copy) NSString *appStoreCountry; This is the two-letter country code used to specify which iTunes store to check. It is set automatically from the device locale preferences, so shouldn't need to be changed in most cases. You can override this to point to the US store, or another specific store if you prefer, which may be a good idea if your app is only available in certain countries, however be warned that this will affect the language used to display the release notes. @property (nonatomic, assign) BOOL showOnFirstLaunch; Specify whether the release notes for the current version should be shown the first time the user launches the app. If set to no it means that users who, for example, download version 1.1 of your app but never installed a previous version, won't be shown the new features in version 1.1. @property (nonatomic, assign) BOOL groupNotesByVersion; If your release notes files contains multiple versions, this option will group the release notes by their version number in the alert shown to the user. If set to NO, the release notes will be shown as a single list. Defaults to NO. @property (nonatomic, assign) float checkPeriod; Sets how frequently the app will check for new releases. This is measured in days but can be set to a fractional value, e.g. 0.5 for half a day. Set this to a higher value to avoid excessive traffic to your server. A value of zero means the app will check every time it's launched. As of iVersion 1.8, the default value is zero. @property (nonatomic, assign) float remindPeriod; How long the app should wait before reminding a user of a new version after they select the "remind me later" option. A value of zero means the app will remind the user every launch. Note that this value supersedes the check period, so once a reminder is set, the app won't check for new releases during the reminder period, even if new version are released in the meantime. The default remind period is one day. @property (nonatomic, copy) NSString *inThisVersionTitle; The title displayed for features in the current version (i.e. features in the local version s plist file). @property (nonatomic, copy) NSString *updateAvailableTitle; The title displayed when iVersion detects a new version of the app has appeared in the remote versions plist. The latest version number will automatically be appended to this title in brackets if groupNotesByVersion is set to NO. @property (nonatomic, copy) NSString *versionLabelFormat; The format string for the release notes version separators. This should include a %@ placeholder for the version number, e.g "Version %@". This label is not used unless groupNotesByVersion is set to YES. @property (nonatomic, copy) NSString *okButtonLabel; The button label for the button to dismiss the "new in this version" modal. @property (nonatomic, copy) NSString *ignoreButtonLabel; The button label for the button the user presses if they do not want to download a new update. @property (nonatomic, copy) NSString *remindButtonLabel; The button label for the button the user presses if they don't want to download a new update immediately, but do want to be reminded about it in future. Set this to @"" if you don't want to display the remind me button - e.g. if you don't have space on screen. @property (nonatomic, copy) NSString *downloadButtonLabel; The button label for the button the user presses if they want to download a new update. @property (nonatomic, assign) BOOL useAllAvailableLanguages; By default, iVersion will use all available languages in the iVersion.bundle, even if used in an app that does not support localisation. If you would prefer to restrict iVersion to only use the same set of languages that your application already supports, set this property to NO (YES by default). @property (nonatomic, assign) BOOL disableAlertViewResizing; On iPhone, iVersion includes some logic to resize the alert view to ensure that your release notes message doesn't become truncated in landscape mode. The code to do this is a rather nasty hack, so if your alert text is very short and/or your app only needs to function in portrait mode on iPhone, you may wish to set this property to YES, which may help make your app more robust against future iOS updates. Try the Resizing Disabled example for a demonstration of the effect. @property (nonatomic, assign) BOOL onlyPromptIfMainWindowIsAvailable; This setting is applicable to Mac OS only. By default, on Mac OS the iVersion alert is displayed as sheet on the main window. Some applications do not have a main window, so this approach doesn't work. For such applications, set this property to NO to allow the iVersion alert to be displayed as a regular modal window. @property (nonatomic, assign) BOOL displayAppUsingStorekitIfAvailable; By default, if iVersion is running on iOS 6 or above then when the user presses Download, the app page will be displayed directly within the app instead of linking to the App Store app. If you don't want that, set this property to NO (YES by default). @property (nonatomic, assign) BOOL useAppStoreDetailsIfNoPlistEntryFound; If you are using the remote plist option, by default iVersion will only display an update alert if a release notes entry is found in that plist, even if a new version is detected on the app store. This allows you to delay the announcement of an update, or block the announcement of minor updates by selectivley omitting versions from the plist. If you would prefer iVersion to use the App Store release notes if no plist entry is found, set this option to YES (NO by default). @property (nonatomic, assign) BOOL checkAtLaunch; Set this to NO to disable checking for local and remote release notes automatically when the app is launched or returns from the background. Disabling this option does not prevent you from manually triggering the checks by calling checkIfNewVersion and checkForNewVersion respectively. @property (nonatomic, assign) BOOL verboseLogging; This option will cause iVersion to send detailed logs to the console about the version checking process. If your app is not correctly detecting a new release, this will help you figure out why. Verbose logging is enabled by default on debug builds, and disabled on release and deployment builds. @property (nonatomic, assign) BOOL previewMode; If set to YES, iVersion will always display the contents of the local and remote versions plists, irrespective of the version number of the current build. Use this to proofread your release notes during testing, but disable it for the final release. Advanced properties If the default iVersion behaviour doesn't meet your requirements, you can implement your own by using the advanced properties, methods and delegate. The properties below let you access internal state and override it: @property (nonatomic, strong) NSURL *updateURL; The URL that the app will direct the user to if an update is detected and they choose to download it. You will need to override this for in-house apps or apps that are not distributed via the App Store. If you are implementing your own download button for a regular app-store-app, you should use the openAppPageInAppStore method instead of opening this URL, especially on Mac OS, as the process for opening the Mac App Store is more complex than merely opening the URL. @property (nonatomic, copy) NSString *ignoredVersion; The version string of the last app version that the user ignored. If the user hasn't ignored any releases, this will be nil. Set this to nil to clear the ignored version. @property (nonatomic, strong) NSDate *lastChecked; The last date on which iVersion checked for an update. You can use this in combination with the checkPeriod to determine if the app should check again. @property (nonatomic, strong) NSDate *lastReminded; The last date on which the user was reminded of a new version. You can use this in combination with the remindPeriod to determine if the app should check again. Set this to nil to clear the reminder delay. @property (nonatomic, assign) BOOL viewedVersionDetails; Flag that indicates if the local version details have been viewed (YES) or not (NO). @property (nonatomic, assign) id<iVersionDelegate> delegate; An object you have supplied that implements the iVersionDelegate protocol, documented below. Use this to detect and/or override iVersion's default behaviour. This defaults to the App Delegate, so if you are using your App Delegate as your iVersion delegate, you don't need to set this property. Advanced methods - (void)openAppPageInAppStore; This method will open the application page in the Mac or iPhone App Store, or directly within the app, depending on which platform and OS version is running. You should use this method instead of the updateURL property, as the process for launching the app store is more complex than merely opening the URL in many cases. Note that this method depends on the appStoreID which is only retrieved after polling the iTunes server, so if you intend to call this method without first doing an update check, you will need to set the appStoreID property yourself beforehand. - (void)checkIfNewVersion; This method will check the local versions Plist to see if there are new notes to be displayed, and will display them in an alert. This method is called automatically on launch if checkAtLaunch is set to YES. - (NSString *)versionDetails; This returns the local release notes for the current version, or any versions that have been released since the last time the app was launched, depending on how many versions are included in the local version plist file. If this isn't the first time this version of the app was launched, only the most recent version is included. - (BOOL)shouldCheckForNewVersion; This method checks to see if the criteria for checking for a new version have been met. You can use this to decide whether to check for version updates if you have disabled the automatic display at app launch. - (void)checkForNewVersion; This method will trigger a new check for new versions, ignoring the checkPeriod and remindPeriod properties. This method is called automatically on launch and when the app returns from background if checkAtLaunch is set to YES and shouldCheckForNewVersion returns YES. Delegate methods The iVersionDelegate protocol provides the following methods that can be used to intercept iVersion events and override the default behaviour. All methods are optional. - (BOOL)iVersionShouldCheckForNewVersion; This is called if the checking criteria have all been met and iVersion is about to check for a new version. If you return NO, the check will not be performed. This method is not called if you trigger the check manually with the checkForNewVersion method. - (void)iVersionDidNotDetectNewVersion; This is called if the version check did not detect any new versions of the application. - (void)iVersionVersionCheckDidFailWithError:(NSError *)error; This is called if the version check failed due to network issues or because the remote versions Plist file was missing or corrupt. - (void)iVersionDidDetectNewVersion:(NSString *)version details:(NSString *)versionDetails; This is called if a new version was detected. - (BOOL)iVersionShouldDisplayNewVersion:(NSString *)version details:(NSString *)versionDetails; This is called immediately before the new (remote) version details alert is displayed. Return NO to prevent the alert from being displayed. Note that if you are implementing the alert yourself you will also need to set the lastChecked, lastReminded and ignoredVersion properties yourself, depending on the user response. - (BOOL)iVersionShouldDisplayCurrentVersionDetails:(NSString *)versionDetails; This is called immediately before the current (local) version details alert is displayed. Return NO to prevent the alert from being displayed. Note that if you intend to implement this notification yourself, you will need to set the viewedVersionDetails flag manually. - (void)iVersionUserDidAttemptToDownloadUpdate:(NSString *)version; This is called when the user pressed the download button in the new version alert. This is useful if you want to log user interaction with iVersion. This method is only called if you are using the standard iVersion alert view and will not be called automatically if you provide a custom alert implementation or call the openAppPageInAppStore method directly. - (void)iVersionUserDidRequestReminderForUpdate:(NSString *)version; This is called when the user asks to be reminded about a new version. This is useful if you want to log user interaction with iVersion. This method is only called if you are using the standard iVersion alert view and will not be called automatically if you provide a custom alert implementation. - (void)iVersionUserDidIgnoreUpdate:(NSString *)version; This is called when the user presses the ignore in the new version alert. This is useful if you want to log user interaction with iVersion. This method is only called if you are using the standard iVersion alert view and will not be called automatically if you provide a custom alert implementation. - (BOOL)iVersionShouldOpenAppStore; This method is called immediately before iVersion attempts to open the App Store, either via a URL or using the StoreKit in-app product view controller. Return NO if you wish to implement your own update page logic. - (void)iVersionDidPresentStoreKitModal; This method is called just after iVersion presents the StoreKit in-app product view controller. It is useful if you want to pause certain functionality in your app, etc. - (void)iVersionDidDismissStoreKitModal; This method is called when the user dismisses the StoreKit in-app product view controller. This is useful if you want to resume any functionality that you paused when the modal was displayed. Localisation The defaults strings for iVersion are already localised for many languages. By default, iVersion will use all the localisations in the iVersion.bundle even in an app that is not localised, or which is only localised to a subset of the languages that iVersion supports. If you would prefer iVersion to only use the localisations that are enabled in your application (so that if your app only supports English, French and Spanish, iVersion will automatically be localised for those languages, but not for German, even though iVersion includes a German language file), set the useAllAvailableLanguages option to NO. iVersion will automatically use the localised release notes that you've specified on iTunes, if available. It is not recommended that you modify the strings files in the iVersion.bundle, as it will complicate updating to newer versions of iVersion. The exception to this is if you would like to submit additional languages or improvements or corrections to the localisations in the iVersion project on github (which are greatly appreciated). If you want to add an additional language for iVersion in your app without submitting them back to the github project, you can add these strings directly to the appropriate Localizable.strings file in your project folder. If you wish to replace some or all of the default iVersion strings, the simplest option is to copy just those strings into your own Localizable.strings file and then modify them. iVersion will automatically use strings in the main application bundle in preference to the ones in the iVersion bundle so you can override any string in this way. If you do not want to use any of the default localisations, you can omit the iVersion.bundle altogether. Note that if you only want to support a subset of languages that iVersion supports, it is not neccesary to delete the other strings files from iVersion.bundle - just set useAllAvailableLanguages to NO, and iVersion will only use the languages that your app already supports. The old method of overriding iVersion's default strings by using individual setter methods (see below) is still supported, however the recommended approach is now to add those strings to your project's Localizable.strings file, which will be detected automatically by iVersion. + (void)initialize { [iVersion sharedInstance].inThisVersionTitle = NSLocalizedString(@"New in this version", @"iVersion local version alert title"); [iVersion sharedInstance].updateAvailableTitle = NSLocalizedString(@"A new version of MyApp is available to download", @"iVersion new version alert title"); [iVersion sharedInstance].versionLabelFormat = NSLocalizedString(@"Version %@", @"iVersion version label format"); [iVersion sharedInstance].okButtonLabel = NSLocalizedString(@"OK", @"iVersion OK button"); [iVersion sharedInstance].ignoreButtonLabel = NSLocalizedString(@"Ignore", @"iVersion ignore button"); [iVersion sharedInstance].remindButtonLabel = NSLocalizedString(@"Remind Me Later", @"iVersion remind button"); [iVersion sharedInstance].downloadButtonLabel = NSLocalizedString(@"Download", @"iVersion download button"); } If you are using the remote versions Plist, and you need to provide localised release notes, the simplest way to do this is to localise the remoteVersionsPlistURL file and provide a different URL for each language, like this: + (void)initialize { [iVersion sharedInstance].remoteVersionsPlistURL = NSLocalizedString(@"http://example.com/versions_en.plist", @"remote iVersion plist URL"); } Example Projects When you build and run the basic Mac or iPhone example project for the first time, it will show an alert saying that a new version is available. This is because it has downloaded the remote versions.plist file and determined that the latest version is newer than the currently running app. Quit the app, go into the iVersion-Info.plist file and edit the bundle version to 1.2. Now rebuild the app. This time it will not say that a new version is available. In effect, you have simulated an upgrade. Instead it will tell you about the new features in your currently installed version. This is because it has found that the bundle version of the current app is newer than the last recorded version that was launched, and has checked the local versions.plist file for a release notes entry for the new version. If you dismiss the dialog and then quit and relaunch the app you should now see nothing. This is because the app has detected that the bundle version hasn't changed since you last launched the app. To show the alerts again, delete the app from the simulator and reset the bundle version to 1.1. Alternatively, enable the previewMode option to force the alerts to appear on launch. Advanced Example The advanced example demonstrates how you might implement a completely bespoke iVersion interface. Automatic version checking is disabled and instead the user can trigger a check by pressing the "Check for new version" button. When pressed, the app display a progress wheel and then prints the result in a console underneath the button. The example is for Mac OS, but the same thing can be applied on iOS.

2011-11-04T12:31:34+00:00 2011-11-04T12:31:34+00:00 http://www.binpress.com/app/icarousel/614 Nick Lockwood noreply@binpress.com http://www.binpress.comdev/profile/5681 A simple, highly customisable, data-driven 3D carousel view for iOS and Mac OSiCarousel is a class designed to simplify the implementation of various types of carousel (paged, scrolling views) on iPhone, iPad and Mac OS. iCarousel implements a number of common effects such as cylindrical, flat and "CoverFlow" style carousels, as well as providing hooks to implement your own bespoke effects. Unlike many other "CoverFlow" libraries, iCarousel can work with any kind of view, not just images, so it is ideal for presenting paged data in a fluid and impressive way in your app. It also makes it extremely easy to swap between different carousel effects with minimal code changes.