Sunday, April 22, 2018

Raspbian - prepare SD card

I already did in the past an article about a SD card preparation for Raspberry Pi.
The idea behind this article is to find a way to simplify and speeding up to prepare an image for a Raspberry Pi with Raspbian and beside, things change constantly.
Here what we need to do now to prepare a Raspbian image (no NOOBS !!!)

Warning !  I did find the latest Raspbian distro "Stretch" not working properly with old Raspberry Pi, up to the version 3.
I used Jessie instead !


The Classic way need you to be able to be connected directly with the Raspberry Pi, so you need a monitor and at least a keyboard. A mouse can be needed if doing GUI.

Shopping list

What we need ?
  • a Raspberry Pi
    For this article I used a Raspberry Pi 3 B+ with the main connection to internet is via WiFi
  • a WiFi network
  • a Keyboard USB
  • a Mouse USB
  • a HDMI monitor
  • a 16 Gbyte Class 10 micro SD card
  • an USB reader for SD cards
  • A Linux machine (in my case based on Ubuntu 16.04 LTS)

SD card preparation

This procedure is to be done only once, the first time.
The image downloaded is the one recent at the preparation date of the article
The examples on the articles imply to use a Linux machine (in my case Ubuntu 16.04)

The SD card better be a 16 Gbyte one so to be able to easily hold different apps and data.
Note that the images downloaded are much smaller than 16 Gbyte, actually they can be from 2 to 4 Gbyte.
Just prepare the SD card formatted in fat32, single partition.  This will be overwritten anyway, is just necessary to allow the Linux system (in my case) to see the SD card.
No need to repartion the SD card after imaged. At the first boot Raspbian will do that, or in any case there is an option on raspi-config.

  • Download Raspbian  
    • Latest version
      At the time of writing the latest distro is Stretch
      Suggested to download the "lite" image since usually the goal is not to use the Raspberry connected to a monitor and a keyboard
      Extract the image from the zip file
    • Previous versions
      (suggested to use Jessie on older machines)
  • Format SD card in Fat32
    Use gparted
  • Go in the directory where the image is
  • Burn the image on the SD card
    Note that in my system the SD card is placed on a USB reader and it appears as /dev/sdd
    sudo dd bs=4M if="image_name" of=/dev/sdd conv=fsync
  • Umount the SD card

Raspberry Pi preparation

  • Insert SD card it in the Raspberry Pi
  • Connect a USB keyboard/mouse to the Raspberry Pi
  • Connect LAN cable
  • Connect HDMI monitor
  • Turn on Raspberry Pi
No internet connection will exists at this stage.
  • After log in from console
    • execute config (sudo raspi-config)
      • change pi user password
      • enable ssh
    • set up WiFi account
      • on Stretch there is a menu on raspi-config
      • on Jessie edit config files 
        • sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
        • Set up the country
        • Add WiFi networks
  • Reboot.  If achieved the WiFi connection (verify with ifconfig)
  • Disconnect video and keyboard
  • Reboot
From now on the connection will be via ssh.
  • After reconnection
    • Update image
      • sudo apt-get update
      • sudo apt-get upgrade
    • install generic building tools
      sudo apt-get install build-essential  
      (note that could be already installed)
At this point the Raspberry Pi is ready for any specific task you need to do.

PiBackery way

PiBackery is a new way to set up a Raspberry Pi I found.
It is much much easier to set up an SD card. Though there are some limitations, for example what distribution to install (I think is limited to the latest one).

Shopping list

What we need ?
  • a Raspberry Pi
    For this article I used a Raspberry Pi 3 B+ with the main connection to internet is via WiFi
  • a WiFi network
  • a 16 Gbyte Class 10 micro SD card
  • an USB reader for SD cards
  • A Windows or Mac (Linux machine are not yet supported)

SD card preparation

This procedure is to be done only once, the first time.
Start the PiBackery program, build your configuration (or import a previous setting saved), insert the SD card, burn it, extract it and insert it in the Raspberry Pi.
Done :)

The main advantage is that the critical parts, setting up WiFi/enable SSH/other things, is done in the SD card burning phase, i.e. the SD card will be come out already configured.
So after that the Raspberry will be activated and ready to be accessed via WiFi.



PiBackery allows to set up two type of boots.
One executed the first time only and one for every time.
Be sure to add in both type of boots the basic configurations, like WiFi, change hostname, etc.
The first boot section should contains basic settings necessary to execute the specific jobs, like installation from internet of packages.


One problem with this approach can be the SSH.
Originally the Raspbian images used as base, had the SSH enabled by default.
The last version of Raspbian, codename Stretch, has the SSH disabled by default.
Because originally the SSH was already enabled, there is "block" to add to the configuration that enable the SSH.
Since is possible for everybody to add a new block, I suggest to :
  1. verify on the PiBakery block latest repository that exists the block you need
  2. If present, just clone and copy the blocks in the installed program
  3. If not present you can add you ssh enable block

Saturday, April 14, 2018

Developer tips - Visual Studio - plist files

Disclaimer !
This article is based on tests/research/finding at April 2018. Things can change.

A project in Visual Studio that involve Apple iOS has some configurations saved in files ending with the .plist suffix.
These files are Property List files.

These files, combined with the project setting, contribute to set up the application configuration that need to match the content of the Provisioning profile.

However the files "per se" contains only few XML lines.

Property Files

A project usually has two of these files :
  • info.plist
  • Entitlement.plist


This file contains some major important setting for the projects.
Note that for Android some of these settings are embedded in the project configuration rather than an external file.
This mechanism is mainly for Apple iOS.


This file contains settings that need to match the Provisioning profile used.

Property Editor

Xamarin has a Property List editor, a GUI based editor for the .plist files.
The  editor goes to modify actually the plist file directly. i.e the information are actually stored in the plist file, there are no redirection to data base or online resources or other hidden stuff nor the plist is populated based on the certificate or provisioning profile issued.

The reason why turning some options ON or Off and nothing happens in the plist file, is because not all the options are actually supported by the Xamarin Plist editor, especially for the Entitlements.
For example the the Data protection and other choices will not produce any effect on the plist file.

The only option usually needed (for the Entitlement.plist file) working is the Push notification.
Note that for the App store the value of such option should be Production and NOT the default Development ( if you leave Development Apple Store will refuse to accept the app).
And of course in the Plist editor you MUST manually edit such value.
If you play with the option only from the GUI, like removing it and reinstating it, it will have the Development value, not the Production.


Developer tips - Visual Studio - Apple iOS development types of build

Disclaimer !
This article is based on tests/research/finding at April 2018. Things can change.

Apple iOS can be a very complicated environment, especially if Xamarin is involved (Visual Studio on Mac).
This article is part of a small collection of notes about some things that usually annoy the developers :) (me)

Ok ok, these are just some notes for me to remember some annoying things

In this episode :

Types of build

When developing an app for iOS on Xamarin, there are 4 different types of build you can chose :

  • Debug
  • Release
  • Ad hoc
  • Distribution
Let see them in more details.


This is the initial type of build during the development of an app.
Usually the build is set to include extra information about debugging and it requires a Developer Provisioning profile.
The app generated in debug can only run on an approved list of devices or in the simulator.


Usually the Release choice allows to compile the code without any debug extra code, similar to the final one, but still using a Developer Provisioning profile.
Like the Debug build, the app can run only an an approved list of devices, usually the same ones used in Debug build.
The app can be loaded on the device directly via iTunes or using systems like TestFlight or TestFairy.

Ad hoc

Like Release above, but it necessary to have a specific Provisioning profile, a Distribution Ad hoc Provisioning profile.
Like the Release, the app can be loaded on the device via direct load (iTunes) or a test environment (TestFlight - TestFairy)


This is the final stage.
When the app is ready for a release on AppStore, must be compiled for Distribution and a specific distribution provisioning profile is needed.
The app can be loaded only on the Apple Store for approval and final distribution.


So, what build to use ?
Well, of course Debug when you need to develop the app.
Then you can create a Release build if the testers have devices in the development list.
If the app need to run on devices not present in the Debug device list, or need to be used by people not in the Development list, then you can create an ad-hoc Provisioning profile with a new list and share the app in that way.
And finally you build for Distribution when the app is ready for the App Store.