Anas AIT-ALI’s Blog

QuickTip Series #3

2017-03-24T00:00:00-04:00

Goal

Display the application version within the app.

Tip

Simply access the main bundle info dictionary with Bundle.main.infoDictionary. You can print this array and see all the information specified in your info.plist.

Example

For example if you want to print the app version and build version (i.e 1.0.0(1)):

func getAppVersion(infoDictionary: [String : Any]? = Bundle.main.infoDictionary) -> String? {
    if let dict = infoDictionary {
        if let version = dict["CFBundleShortVersionString"] as? String,
            let bundleVersion = dict["CFBundleVersion"] as? String {
	         return "\(version)(\(bundleVersion))"
        }
    }
    return nil
}

print(getAppVersion()) // => will display 1.0.0(0)

Simple!

Pod: AABlurAlertController

2017-02-06T00:00:00-05:00

As often my work is done for companies or personal projects, I don’t often end up sharing what I do.

So from time to time, I like to take a moment to create a pod out of some code that I wrote for something else. And if people like it and use it, I am more than happy to work on it and adapt it to their needs. It’s just my way to say thank you to all the people out there making amazing libraries that I use myself.

Anyway, I’ve decided to share them also on my blog now.
And this is the first one that I would like to post here.

I’m really bad at finding a name, so I decided to call it: AABlurAlertController.
It is a custom alert controller with a blurred background that you can use anywhere in your app.
It is fully written in Swift (3.0 as I’m writing this).

You can find it on Github at : AABlurAlertController

Hope you like it.

QuickTip Series #2

2016-07-31T00:00:00-04:00

Hello guys,
No introduction needed! Let’s go straight for our quick tip number 2.

Goal

Debug the view controllers hierarchy in the console as sometimes the Xcode UI Debugger can’t give us what we are looking for

Tip

Add a breakpoint where you want to debug the views and put the following code in the debugger console once you reach your breakpoint:
Run the command in the lldb console

When debugging Objective-C code:

po [UIViewController _printHierarchy]

and for Swift:

expr -l objc++ -O -- [UIViewController _printHierarchy]

Example

Below an output example of when using this command :

<PieOverlayMenu.PieOverlayMenu 0x7f86854755e0>, state: appeared, view: <UIView 0x7f868548c500>
   | <Pie_for_Drivers.SplitViewController 0x7f8686877800>, state: appeared, view: <UILayoutContainerView 0x7f8684ce8410>
   |    | <UINavigationController 0x7f8688896200>, state: appeared, view: <UILayoutContainerView 0x7f8685417d10>
   |    |    | <Pie_for_Drivers.LegsListViewController 0x7f8685604f40>, state: appeared, view: <UIView 0x7f8684d51290>
   |    | <Pie_for_Drivers.MapViewController 0x7f8685416e10>, state: appeared, view: <UIView 0x7f86851dab80>
   | <PieOverlayMenu.PieOverlayMenuContentViewController 0x7f8685476080>, state: appeared, view: <UIView 0x7f86855423c0>
   |    | <Pie_for_Drivers.MenuViewController 0x7f8685474320>, state: appeared, view: <UIView 0x7f86854845b0>

Under the hood

Apple added the debub view hierarchy feature in XCode 6. But to inspect the view controller hierarchy Apple only introduced this private helper : _printHierarchy silently in iOS 8.

Let me now explain what the expression does.
Basically, it’s just calling the private helper :P

However, the command is different for Swift and Objective-C simply because the methode _printHierarchy isn’t available in Swift.
So what we do here is that we tell LLDB to execute an Objective-C expression.

Let’s break down the command for Swift code :

po (for print object) is simply an alias to expr -O --
-l objc++ is here to specify the language used.

Voila!

QuickTip Series #1

2016-07-17T00:00:00-04:00

Hello there,
I’m so excited to start this Quicktip series today. The goal of this serie of articles is to give you some tips in a short, precise and consise way. So enough talk and let’s get started.

Goal

The idea is to be able to have different podfile configurations based on the current environnement.

Tip

Simply check environnement variables in your podfile.
You can access and environnement variable this way : ENV['USER']

Example

source 'https://github.com/CocoaPods/Specs.git'

platform :ios, '8.0'
use_frameworks!
inhibit_all_warnings!

target 'TargetName' do

    if ['anas'].include?(ENV['USER']) #1
    	# IF CURRENT USER IS ME, I use the local path
    	pod 'AABlurAlertController', :path => "#{ENV['POD_LOCAL_HOME']}/AABlurAlertController"
    	
       else
       # ELSE (CI for example) I use the github repository
       pod 'AABlurAlertController', :git => 'git@github.com:anas10/AABlurAlertController.git', :branch => 'master'
       
    end

    pod 'AASquaresLoading'
	[...]
	
    target 'TargetNameTests' do
        inherit! :search_paths
        
		 [...]
    end
end

The important part is #1 where we check the environement user and then act accordingly.

Here we go with our first quick tip.
Let me know what you think and see you soon.

UPDATE : 04/04/17

I did something else recently that makes more sense in many cases.
Instead of looking for the user via an environment variable, I just look for a specific environnement variable such as LOCALPODS

if ENV['LOCALPODS']
	pod 'AABlurAlertController', :path => "#{ENV['POD_LOCAL_HOME']}/AABlurAlertController"    
else
	pod 'AABlurAlertController', :git => 'git@github.com:anas10/AABlurAlertController.git', :branch => 'master'
end

Ans I set this variable only when needed before a pod install like this : LOCALPODS=true pod install

Welcome

2016-07-13T00:00:00-04:00

Welcome to my blog.

I always had notes about projects, tech stuff, ideas and so on. But they were always private and only accessible to me. It was like my personal journal. And now I decided to simply share that with who may be interested :)

Hope you’ll like it.