March 3, 2015 at 12:18How to simplify the life of iOS developer
Probably, every developer, when he begins to master a new technology, wants to try everything on his own, to realize everything from the lowest level, then to enjoy the result of his work. However, with the accumulation of experience, many tasks become quite boring and I want to save myself from this necessary, but uninteresting routine. In this article I want to share what methods and tools will help simplify the life of the developer and save nerves.
This is one of the first and easiest, but still significant actions, but many articles have already been written about this, such as this , this , this, and there is hardly any developer who does not know this, so we will not stop here. Also, quite a lot of useful plugins have been written for Xcode, an overview article on which can be read here .
In addition to connecting your favorite or needed libraries for this project through CocoaPods, you can add your own repository with the most common “helper functions”. For example, who is not tired of writing code like this:
or
To rid myself of this, I use a repository on GitHub with useful categories that will greatly reduce coding. Using it, all this can be rewritten as follows:
Almost always it is required to make at least two or three project locations. Xcode has its own tools for this, and you have to give credit to the Apple developers for improving them, but still this is not the most convenient way, especially if the application is already in the AppStore and you need to release an update - there are enough problems like with Base Internationalization, so with Localizable.Strings. Those who have already encountered this know that Xcode is not able to append or update values in localized * .strings files for the Storyboard, and the genstrings utility expects only new added lines to enter, unless we want to regenerate all the entries again.
Let's start with Localizable.Strings. I highlight a separate h-file for NSLocalizedString, for example StringConstants.h, in which localized strings are defined through #define. With this approach, you can kill two birds with one stone:
As for the generation of localized files, for this I use the second h-file, NewStringConstants.h, in which I add the entries that need to be localized, and then delete them. Directly in Localizable.Strings, the new entries are added by the script in Build Phases:
All that remains to be done after this is to write local string values in Localizable.Strings files.
With Storyboard, the task is also solved through a script, which is discussed in detail in thisarticle. Here I want to briefly mention that the essence of the script is that it extracts lines from the Storyboard using the ibtool utility, and when called, it checks to see if any changes have occurred. If the latter are present, the export of localized strings is done, after which the localized files are merged. Again, it remains to fix the localized files. I also want to mention the AppleGlot tool, which is mentioned in the article above, however, it takes a different approach in iterative updating of localization. The choice of a specific tool is up to the developer, depending on his preferences.
Here we will focus on manual testing of the application in a limited number of devices. No matter how much code is covered by unit tests, manual testing cannot be ruled out. Basically, the developer himself does this during the creation of the application, but when it is ready, you need to transfer the application to an ordinary user who does not have his eyes “blurred” and who will use the application as an average user uninitiated in all the details of the work. It’s good if you have a whole set of devices with all supported operating systems, but basically this is not so. Even if there is a whole line of devices, then, as a rule, they do not differ in the variety of operating systems, which basically, of course, is not necessary, but it will not hurt to check. An iOS simulator will come to the rescue, which can be configured by selecting the desired item from the drop-down menu. However, without additional actions, the tester will have to transfer the source codes, which is not always acceptable. Next, I will describe how you can transfer the assembled application for testing on the iOS simulator and what additional software needs to be installed for this.
sim_launcher allows you to run iOS applications in the simulator via HTTP GET requests. This is convenient because all organizational work for testing can be organized in a browser without forcing the user to remember terminal commands. ios-sim is a kind of wrapper on the terminal commands, simplifying the work with the simulator. It seems that sim_launcher has not been updated for some time, so it is not compatible with the latest version of ios-sim. You need to fix the following functions in the simulator.rb file located in the sim_launcher installation folder:
This command lifts a web service on port 8881. Specifying insteadfull path to the .app file, go to the browser at http: // localhost: 8881 / launch_iphone_app? sdk = com.apple.CoreSimulator.SimDeviceType.iPhone-6,% 208.1 & app_path =
Running the simulator from the browser is convenient, but manually typing the address is not very healthy. You can make up a small html page that would provide some convenient UI to the tester. The simplest implementation is as follows:
The list of simulators that are currently available for launch through ios-sim can be obtained using the command
I think that a lot of iOS developers are also at the same time, if not experienced, then quite advanced users of Adobe Photoshop, as sometimes you have to modify or export something from layouts. To cut the interface elements, you can connect a script that will do this in a couple of clicks.
For a good design of the application page in the AppStore, it must be provided with appropriate screenshots. In addition to the need to make them for each supported device, you must also take care of all localizations. Without automation, this process also carries thepain of a lot of routine work. On the website fastlane.toolsThe scheme of automation of many processes related to testing, continuous integration, as well as publication of the application is given. All source codes are available in the public domain, and there is also an instruction for them. Here I just want to comment on the part on working with screenshots. Using UI Automation, a script is prepared that the simulator will execute in automatic mode, in the right places of which you need to add a screenshot creation command. Separate scripts are supported for phones and tablets. All screenshots are sorted by localization and stacked in separate folders, and an overview html page is also generated. Using another script, all screenshots can be downloaded to iTunesConnect also without user intervention. Thus, it remains only to configure the parameters.
On this I would like to complete this article. I hope it will be useful not only to those who have just started to learn or are interested in the delights of iOS development, but also to experienced developers who may not have known that a lot of boring work can be entrusted to a computer, leaving yourself the most interesting development. In the comments, I propose to discuss, if any, other tools and ways to speed up or simplify some tasks.
Setting up a project, development environment, connecting libraries, snippets
This is one of the first and easiest, but still significant actions, but many articles have already been written about this, such as this , this , this, and there is hardly any developer who does not know this, so we will not stop here. Also, quite a lot of useful plugins have been written for Xcode, an overview article on which can be read here .
Your CocoaPods Repository
In addition to connecting your favorite or needed libraries for this project through CocoaPods, you can add your own repository with the most common “helper functions”. For example, who is not tired of writing code like this:
[self.subviews makeObjectsPerformSelector:@selector(removeFromSuperview)];or
NSData *data = [responseString dataUsingEncoding:NSUTF8StringEncoding];
return [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:nil];To rid myself of this, I use a repository on GitHub with useful categories that will greatly reduce coding. Using it, all this can be rewritten as follows:
[self removeAllSubviews];
return responseString.JSON;Application localization
Almost always it is required to make at least two or three project locations. Xcode has its own tools for this, and you have to give credit to the Apple developers for improving them, but still this is not the most convenient way, especially if the application is already in the AppStore and you need to release an update - there are enough problems like with Base Internationalization, so with Localizable.Strings. Those who have already encountered this know that Xcode is not able to append or update values in localized * .strings files for the Storyboard, and the genstrings utility expects only new added lines to enter, unless we want to regenerate all the entries again.
Let's start with Localizable.Strings. I highlight a separate h-file for NSLocalizedString, for example StringConstants.h, in which localized strings are defined through #define. With this approach, you can kill two birds with one stone:
- Collect common phrases and words, such as “Cancel”, “Logout”, “Invalid username or password”, etc., which are likely to be present in any project, so that you can carry it with you with ready-made lines
- Reuse existing lines within the project without typing the long and uncomfortable NSLocalizedString macro each time
[[[UIAlertView alloc] initWithTitle:kErrorString
message:kInvalidLoginOrPasswordString
delegate:nil
cancelButtonTitle:@"OK"
otherButtonTitles:nil] show];
As for the generation of localized files, for this I use the second h-file, NewStringConstants.h, in which I add the entries that need to be localized, and then delete them. Directly in Localizable.Strings, the new entries are added by the script in Build Phases:
cd ${PROJECT_DIR}/MyProject
genstrings -a -o Base.lproj NewStringConstants.h
genstrings -a -o ru.lproj NewStringConstants.h
genstrings -a -o pt-PT.lproj NewStringConstants.h
genstrings -a -o es.lproj NewStringConstants.hAll that remains to be done after this is to write local string values in Localizable.Strings files.
With Storyboard, the task is also solved through a script, which is discussed in detail in thisarticle. Here I want to briefly mention that the essence of the script is that it extracts lines from the Storyboard using the ibtool utility, and when called, it checks to see if any changes have occurred. If the latter are present, the export of localized strings is done, after which the localized files are merged. Again, it remains to fix the localized files. I also want to mention the AppleGlot tool, which is mentioned in the article above, however, it takes a different approach in iterative updating of localization. The choice of a specific tool is up to the developer, depending on his preferences.
Application testing
Here we will focus on manual testing of the application in a limited number of devices. No matter how much code is covered by unit tests, manual testing cannot be ruled out. Basically, the developer himself does this during the creation of the application, but when it is ready, you need to transfer the application to an ordinary user who does not have his eyes “blurred” and who will use the application as an average user uninitiated in all the details of the work. It’s good if you have a whole set of devices with all supported operating systems, but basically this is not so. Even if there is a whole line of devices, then, as a rule, they do not differ in the variety of operating systems, which basically, of course, is not necessary, but it will not hurt to check. An iOS simulator will come to the rescue, which can be configured by selecting the desired item from the drop-down menu. However, without additional actions, the tester will have to transfer the source codes, which is not always acceptable. Next, I will describe how you can transfer the assembled application for testing on the iOS simulator and what additional software needs to be installed for this.
Install sim_launcher and ios-sim
gem install sim_launcher
brew install ios-simsim_launcher allows you to run iOS applications in the simulator via HTTP GET requests. This is convenient because all organizational work for testing can be organized in a browser without forcing the user to remember terminal commands. ios-sim is a kind of wrapper on the terminal commands, simplifying the work with the simulator. It seems that sim_launcher has not been updated for some time, so it is not compatible with the latest version of ios-sim. You need to fix the following functions in the simulator.rb file located in the sim_launcher installation folder:
Fixes simulator.rb
def start_simulator(sdk_version, device_family)
sdk_version ||= SdkDetector.new(self).latest_sdk_version
run_synchronous_command( :start, '--devicetypeid', sdk_version, '--exit' )
end
def launch_ios_app(app_path, sdk_version, device_family, app_args = nil)
if problem = SimLauncher.check_app_path( app_path )
bangs = '!'*80
raise "\n#{bangs}\nENCOUNTERED A PROBLEM WITH THE SPECIFIED APP PATH:\n\n#{problem}\n#{bangs}"
end
sdk_version ||= SdkDetector.new(self).latest_sdk_version
args = ["--args"] + app_args.flatten if app_args
run_synchronous_command( :launch, app_path, '--devicetypeid', sdk_version, '--exit', *args )
endRunning the build on the simulator
sim_launcherThis command lifts a web service on port 8881. Specifying instead
xcodebuild -workspace MyProject.xcworkspace -scheme MyProject -arch i386 -sdk iphonesimulatorFinishing touches
Running the simulator from the browser is convenient, but manually typing the address is not very healthy. You can make up a small html page that would provide some convenient UI to the tester. The simplest implementation is as follows:
HTML code
Testing utility The list of simulators that are currently available for launch through ios-sim can be obtained using the command
ios-sim showdevicetypesDesign cutting
I think that a lot of iOS developers are also at the same time, if not experienced, then quite advanced users of Adobe Photoshop, as sometimes you have to modify or export something from layouts. To cut the interface elements, you can connect a script that will do this in a couple of clicks.
Publish Application
For a good design of the application page in the AppStore, it must be provided with appropriate screenshots. In addition to the need to make them for each supported device, you must also take care of all localizations. Without automation, this process also carries the
On this I would like to complete this article. I hope it will be useful not only to those who have just started to learn or are interested in the delights of iOS development, but also to experienced developers who may not have known that a lot of boring work can be entrusted to a computer, leaving yourself the most interesting development. In the comments, I propose to discuss, if any, other tools and ways to speed up or simplify some tasks.