iOS iPhone Entwicklung in Xcode 4.4 (auch Xcode 5) – Erstellen eines korrekten Provisioning Profiles (Dev & Distri) + Zertifikate

Achtung: Diese Anleitung wurde am 08. August 2012 geschrieben. Sie funktioniert noch! Wer aber eine Verbesserung oder vor allem eine Neuerung hat, der schreibe mir dies! Danke sehr.

Ich machte schon ein paar Tage rum, ehe ich es geschafft habe ein korrektes Provisioning Profile für Development und Distribution im iOS Provisioning Portal hinzubekommen. Inklusive der dazugehörigen Certificates.
Ich dachte immer ich sei eigentlich am Ziel, jedoch brachte mich die Fehlermeldung “A valid signing identity not found” im Xcode Organizer sowohl als auch im Xcode Archiving direkt nahezu dazu, meinen iMac aus dem Fenster zu werfen.

Nun habe ich herausgefunden wie man korrekte Development und Distribution Provisioning Profiles erstellt und die dazugehörigen Zertifikate im Schlüsselbund.

Wenn Ihr die Anleitung genau befolgt, sollte Euch das ab sofort auch möglich sein. In meiner Ausführung gehe ich von grundsätzlichen OS X-Basics aus. So verlange ich beispielsweise in einem Punkt die Schlüsselbundverwaltung zu öffnen. Hier gehe ich davon aus, dass man weiß wie das geht. Diese Schritte werde ich nicht extra erklären.
Schritt für Schritt: Continue reading

Ende besiegelt: Flash stirbt zum 15. August 2012 für Smartphones

Und er hatte doch recht: Laut dem offiziellen Adobe-Blog wird Flash ab dem 15.08.2012 nur noch für den PC-Bereich weiterentwickelt. HTML 5 (was ist HTML 5) wird die ganze Geschichte für die Mobilsparte dann übernehmen.

Android Jelly Bean (= Android 4.1, Wiki) wird offiziell von Adobe nicht unterstützt. Zwar kann man mit Jelly Bean weiterhin Flash nutzen, da es dafür seitens Adobe keine Anpassung dafür gibt und der Hersteller sogar empfiehlt Flash unter 4.1 zu deinstallieren, sollte man zumindest davon ausgehen, dass der Player unter dem derzeit neuesten Android “Mukken” machen könnte…

Android-Nutzer, die den Flashplayer weiterhin nutzen möchten, sollten also bis zum 15.08. den Player aus Google Play downloaden. Wer den Player besitzt kann dann ab dem festgesetzten Datum nur noch anstehende Sicherheitsupdates laden.

iOS-Nutzern dürfte damit das letzte Hindernis zum perfekten Betriebssystem aus dem Weg geräumt sein. Wobei Kenner der IT-Szene bereits über die vielen Nachteile von Flash auf einem Smartphone bescheid wussten (Beispiele: Sicherheit, Akkuverbrauch etc…).

Meine Persönliche Meinung ist, dass Flash-Webinhalte, vor allem im Mobilen Bereich immer mehr in der “Senke”verschwinden werden. HTML 5 wird der neue Standard werden, der sich dann nach und nach vollends durchsetzen wird.

Update: 28.09.2019

Der Adobe-Blogeintrag ist nun öffentlich nicht mehr einsehbar. Er wurde wohl archiviert. Anbei der Originaltext:

We announced last November that we are focusing our work with Flash on PC browsing and mobile apps packaged with Adobe AIR, and will be discontinuing our development of the Flash Player for mobile browsers.  This post provides an update on what this means for ongoing access to the Flash Player browser plugin for Android in the Google Play Store.

The Flash Player browser plugin integrates tightly with a device’s browser and multimedia subsystems (in ways that typical apps do not), and this necessitates integration by our device ecosystem partners.  To ensure that  the Flash Player provides the best possible experience for users, our partner program requires certification of each Flash Player implementation.  Certification includes extensive testing to ensure web content works as expected, and that the Flash Player provides a good user experience. Certified devices typically include the Flash Player pre-loaded at the factory or as part of a system update.

Devices that don’t have the Flash Player provided by the manufacturer typically are uncertified, meaning the manufacturer has not completed the certification testing requirements. In many cases users of uncertified devices have been able to download the Flash Player from the Google Play Store, and in most cases it worked. However, with Android 4.1 this is no longer going to be the case, as we have not continued developing and testing Flash Player for this new version of Android and its available browser options.  There will be no certified implementations of Flash Player for Android 4.1.

Beginning August 15th we will use the configuration settings in the Google Play Store to limit continued access to Flash Player updates to only those devices that have Flash Player already installed. Devices that do not have Flash Player already installed are increasingly likely to be incompatible with Flash Player and will no longer be able to install it from the Google Play Store after August 15th.

The easiest way to ensure ongoing access to Flash Player on Android 4.0 or earlier devices is to use certified devices and ensure that the Flash Player is either pre-installed by the manufacturer or installed from Google Play Store before August 15th. If a device is upgraded from Android 4.0 to Android 4.1, the current version of Flash Player may exhibit unpredictable behavior, as it is not certified for use with Android 4.1.  Future updates to Flash Player will not work.  We recommend uninstalling Flash Player on devices which have been upgraded to Android 4.1.

For developers who need ongoing access to released versions of Flash Player for Android, those will remain available in the adobe archive of released Flash Player versions.  Installations made from the archive will not receive updates through the Google Play Store.

As always this and other Flash runtime roadmap updates can be found in the Adobe roadmap for the Flash runtimes white paper.

If you are using the mobile browser with Flash for video playback, please see our blog post here about various options available to help with this change.

Internet Explorer 8 Remote installieren

Viele Administratoren werden sicherlich schon einmal vor der Problem gestanden haben, ein Programm auf mehreren Rechnern (nach-)installieren zu müssen, ohne dafür auf eine richtige Softwareverteilung zurückgreifen zu können. In so einem Falle hat man mehrere Möglichkeiten: Entweder man nimmt sich jeden Rechner einzeln vor, oder man baut sich seine eigene “Softwareverteilung”. Ersteres dürfte wohl nur in relativ kleinen Netzwerken eine ernsthaft zu erwägende Option sein, da der Zeitaufwand spätestens ab zehn Rechnern in unverhältnismäßige Dimensionen steigt. Bleibt also nur der zweite Weg – und die Frage nach dem “Wie?”…

… Welche sich denn auch recht schnell und einfach beantworten lässt: mit knapp 60 Zeilen Skriptcode, ein wenig Basiswissen im Umgang mit VBScript und WMI, sowie einer passenden Installationsdatei. Im Falle des Internet Explorer 8 empfiehlt es sich, ein MSI-Paket zu verwenden, welches man sich aber leider erst selbst mit dem Internet Explorer Administration Kit (IEAK) 8 erstellen muss. Ist dies soweit gelungen, kann man sich an das Installationsskript machen. Ziel ist es, dass das Skript zentral ausgeführt wird und dann automatisch die Installation auf allen angegebenen Rechnern vornimmt. Und das Ergebnis sieht wie folgt aus:

'## Remote-Installationsskript v1.5 ##

Program = "Internet Explorer 8"
SrcPath = "P:\Browser\Internet_Explorer_8\"
SetupFile = "IE8-Setup-Full.msi"
InstOptions = " /quiet /qn /norestart"
ComputerListe = "ComputerListe.txt"
LogFile = ScrPath & Program & " Installation.log"

Set fso = createobject("scripting.filesystemobject")
Set oLogging = fso.OpenTextFile(LogFile, 8, true)
Set oComputerListe = fso.opentextfile(ComputerListe, 1, false)
if (Err.Number <> 0) then
WScript.echo "Cannot open " & ComputerListe
WScript.quit
end if

WScript.Echo "Beginning Remote Installation."

on error resume next

while not oComputerListe.atEndOfStream
Computer = oComputerListe.ReadLine()

'WScript.echo "Copying files to " & Computer & " ..."

fso.CopyFile SrcPath & SetupFile, "\\" & Computer & "\C$\Temp\", true
if (Err.Number <> 0) then
WScript.echo "Failed to copy File(s) on " & Computer & " with " & Err.Number
end if

Err.Clear

'WScript.echo "Connecting to " & Computer & "..."

if (Err.Number <> 0) then
WScript.echo "Failed to connect to " & Computer & "."
else

'WScript.echo "Installing " & Program

Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & Computer & "\root\cimv2")
Set oProcess = oWMI.Get("win32_process")
oProcess.create "C:\Windows\System32\msiexec.exe /i C:\Temp\" & SetupFile & InstOptions
if (Err.Number <> 0) then
WScript.echo "Failed to start process on " & Computer & ": " & Err.Number
else
oLogging.WriteLine(Computer & ": " & Date)
end if
end if

Err.Clear

wend

oComputerListe.close()
oLogging.close()

WScript.echo "Exiting."

Das Skript greift auf die Datei “ComputerListe.txt” zu, in der die Zielhosts mit Name oder IP-Adresse definiert sind. Auf jeden Host wird das MSI-Paket nach C:\Temp kopiert. Ist der Kopiervorgang erfolgreich abgeschlossen, stellt das Skript eine WMI-Verbindung mit dem Zielhost her und startet auf diesem den Setupprozess. Ein fehlerfreier Start wird in einer Logdatei mit Datum protokolliert, eventuelle Fehlermeldung werden auf den Bildschirm ausgegeben. WICHTIG: Der Account, unter dem das Skript ausgeführt wird, benötigt auf den Ziel PCs die notwendigen Rechte, um auf WMI zugreifen und Programme installieren zu können. Im günstigsten Falle startet man das Skript also unter einem Domänenadmin-Account.

Natürlich ist dies bei weitem nicht mit einer wirklichen Softwareverteilung zu vergleichen, aber mit ein Bisschen Fleißarbeit kann man das Skript noch etwas aufbohren. So können z.B. Hosts aus einem Active Directory ausgelesen werden, anstelle aus der Textdatei. Ebenso kann man auch durch Überprüfung der Installationslogs auf den Rechnern das Ergebnis der Installation abprüfen und dieses z.B. in eine Datenbank schreiben – VBScript bietet hier viele Möglichkeiten, die man sich mit ein wenig Zeit und Lust zu nutze machen kann. Viel Spaß beim Skripten!