將C/C++程式從Windows (VS)移植到OSX (Xcode) - Platform Header File, Part 2

不同的平台有時候用的library不一樣，最標準的就是GUI的framework，所以移植程式到不同平台很重要的一個部分是讓程式裡可以知道編譯的是什麼平台，這樣就可以呼叫這個平台對映的程式碼。

我的做法很簡單，就是定義一個標頭檔nPlatform.h，讓其他的程式碼一定要include進來，這樣就可以在編譯(compile)知道是哪一個平台了。

#ifndef nPlatform_h
#define nPlatform_h

#if (defined(NS_WIN32) || defined(WIN32))
 #define NS_PLATFORM_WIN32  1
 #define NS_PLATFORM_WINDOWS  1
#elif (defined(_WIN32_WCE) || defined(NS_WINCE))
 #define NS_PLATFORM_WINCE  1
 #define NS_PLATFORM_WINDOWS  1
#elif (defined(__ANDROID__) || defined(NS_ANDROID))
 #define NS_PLATFORM_ANDROID 1
 #define NS_PLATFORM_LINUX 1
#elif (defined(__APPLE__))
    #define NS_APPLE 1
    #include "TargetConditionals.h"
    #if TARGET_IPHONE_SIMULATOR
    // iOS Simulator
        #define NS_PLATFORM_IOS 1
    #elif TARGET_OS_IPHONE
    // iOS device
        #define NS_PLATFORM_IOS 1
    #elif TARGET_OS_MAC
    // Other kinds of Mac OS
        #define NS_PLATFORM_OSX 1
    #else
    // Unsupported platform
        DASSERT(0);
    #endif
#else
 DASSERT(0);
#endif
#endif // nPlatform_h

從上面的程式碼可以知道，在Mac裡頭是使用#elif (defined(__APPLE__))來決定編譯環境的，一旦程式檔include這個標頭檔，就可以知道目前的平台了。

其實為了避免，不同平台的函式呼叫散步在這個項目中，通常會在底層的部分將這些不同函式呼叫集中起來，上層一律使用包裝過的類別或者Api，就可以將跨平台的移植負擔最小化。

舉個例子，我會將檔案存取(file access)的函式特別包裝一個類別，實作的部分會根據不同平台使用不同的函式，上層程式碼就一律呼叫這個特定的類別，這樣發展就可以簡單了一些。

nsFile類別

/*
 * class for file
 */
// define SEEK method.
#ifndef SEEK_SET
#define SEEK_SET        0
#endif
#ifndef SEEK_CUR
#define SEEK_CUR        1
#endif
#ifndef SEEK_END
#define SEEK_END        2
#endif

class nsFile 
{
public:
 enum StateType_E 
 {
  IFEXIST = 0x01,
  IFDIR = 0x02,
  IFREG = 0x04
 };

 static const char DELM;
    static const char* DELM_STR; 
 static const wchar_t DELM_W;
 static const wchar_t* DELM_STR_W; 

    static int stat(const nsUChar_T* filename);
    static bool isAbsPath(const nsUChar_T* full_path);
    static bool isExecutable(const nsUChar_T* filename);
    static long getSize(const nsUChar_T* filename);
    static bool copy(const nsUChar_T* src, const nsUChar_T* dest);
    static bool remove(const nsUChar_T* filename);
    static bool move(const nsUChar_T* src, const nsUChar_T* dest);
    static bool isDir(const nsUChar_T* filename) { return (stat(filename)&IFDIR)?true:false; }
    static bool isRegular(const nsUChar_T* filename) { return (stat(filename)&IFREG)?true:false; }
    static bool isExist(const nsUChar_T* filename) { return (stat(filename)&IFEXIST)?true:false; }

 enum Mode_E
 {
  eREAD = 0x01,
  eWRITE = 0x02,
  //eAPPEND = 0x04
 };

 nsFile();
 ~nsFile();
 bool open(const nsUChar_T* path, int mode);
 void close();
 void flush();
 U64 size();
 U64 seek(U64 offset, int origin);
 U64 tell();
 U32 read(void*, U32, U32);
 U32 write(void*, U32, U32);

private:
 int _mode;
#ifdef NS_PLATFORM_WINDOWS
 FILE* _fd;
#elif NS_APPLE
    FILE* _fd;
#else
 int _fd;
 //FILE* _fd;
#endif
};

nsFile類別實作範例

bool
nsFile::open(const nsUChar_T* path, int mode)
{
 _mode = mode;
#ifdef NS_PLATFORM_WIN32
 if (mode&eREAD) {
  _fd = _wfopen((wchar_t*)path, L"rb+");
 }
 else if (mode&eWRITE) {
  _fd = _wfopen((wchar_t*)path, L"wb+");
 }
#elif NS_PLATFORM_OSX
    static char cpath[1024];
    memset(cpath, 0, 1024);
    nsUStr::toMultiBytes(path, cpath, 1024);
    if (mode&eREAD) {
        _fd = fopen(cpath, "rb+");
    }
    else if (mode&eWRITE) {
        _fd = fopen(cpath, "wb+");
    }

#else
 static char cpath[1024];
 memset(cpath, 0, 1024);
 nsUStr::toMultiBytes(path, cpath, 1024);
 if (mode&eREAD) {
  _fd = ::open(cpath, O_RDONLY);
 }
 else if (mode&eWRITE) {
  _fd = ::open(cpath, O_RDWR | O_CREAT | O_TRUNC, S_IRWXU|S_IRWXG|S_IRWXO);
 }
endif
 return ((_fd)?true:false);
}

void
nsFile::close()
{
 if (_fd) {
#ifdef NS_PLATFORM_WINDOWS
  fclose(_fd);
#elif NS_APPLE
        fclose(_fd);
#else
  ::close(_fd);
#endif
 }
}

其實，上面的範例其實可以在Windows，OSX，Linux(Android)三個平台正常使用的，是我已經驗證過的。

將C/C++程式從Windows (VS)移植到OSX (Xcode) - Part I

最近為了一些經書撰寫了一版資料結構，一開始在Windows下面寫的，用的是Visual Studio 2005這個環境來編譯。因為當初這個資料結構服務的程式是手持設備，所以當初設計的時候有考量到往後可能有移植的需求，這個環境是使用cmake來建立。

為什麼會使用cmake呢？其實以前在建立公司的環境時曾經使用tmake，可是後來發現tmake已經沒有人在維護，如果以後要支援Android，iOS可能會不適用，新建系統的時候就直接放棄了，評估了一陣子就選擇cmake當成跨平台的發展環境，一直到今天還覺得當初有做這樣的決定。

在cmake環境下，重要的是寫好CMakeLists.txt這個描述檔（詳細內容就不在這邊說明了，請參考cmake的網站），一旦寫好，可以透過cmake產生不同的發展環境的project檔。因為我是使用Visual Studio 2005，簡單指令就可以產生sln檔，然後叫起VS來編譯。

cmake -G "Visual Studio 8 2005" ../src

這些日子為了將App從Android移植到iOS來，所以就買了一台MacBook Pro，就希望以前發展的程式可以在OSX下面編譯並執行。研究了一下，就發現cmake的好，在mac check out程式碼後，同樣用cmake來生成Xcode的project檔，接著啟動 Xcode打開程式檔，就可以進行編譯了。

cmake -G Xcode ../src

但是，在利用Xcode編譯的過程，標頭檔(Header files)似乎不會複製到指定的位置去，所以只能手動完成。

cmake -P cmake_install.cmake

Xcode跑起來的截圖

簡單吧，看起來是很簡單，至少環境的部分是這樣。但是程式碼本身才是重點，下回再講講程式碼本身是如何移植的。

App - Locations by GPX (GPX位置產生器)

 Locations by GPX (GPX位置產生器)

今天發表了一個App - Locations by GPX (GPX位置產生器)可以利用GPX檔案來模擬GPS的訊號，用來測試會用到GPS訊號的App很有用。

使用前一定要：
1. 『設定』要開啓『開發人員選項』
2. 在『開發人員選項』裡要開啓『允許模擬位置』

使用方法：
1. 匯入GPX檔案

2. 播放GPX檔案

3. 目前播放狀態

下載位置: Locations by GPX (GPX位置產生器)

今天我學到 - 為什麼在Android Studio裡PackageInfo的versionName為null？

將舊的Project改到Android Studio的環境中，遇到了一個問題。原本透過PackageInfo來查詢的versionName變成null，看一下AndroidManifest.xml也沒有錯（如下），為什麼會這樣呢？

    android:versionCode="3300"
    android:versionName="3.3.00">

原來是Gradle的原因，需要在Project裡的build.gradle，加上面描述才行。

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        minSdkVersion 10
        targetSdkVersion 19
        versionCode 3300
        versionName "3.3.00"
    }

舊Project搬到Android Studio實在有很多『梅軋』，找時間慢慢寫出來。

今天我學到 - startActivityForResult總是收到RESULT_CANCELED的問題

startActivityForResult總是收到RESULT_CANCELED的問題

程式中，啟動相片程式去選取相片，但是相片程式還沒啟動時，Activity就收到RESULT_CANCELED的回傳，而且屢試不爽，仔細查了一下終於發現原因了。

檢查AndriodManifest.xml，找到您的Activity，看看是否有下面這行：

android:launchMode="singleInstance"

如果有的話，找到了，無論時singleInstance或者是singleTask，都沒有辦法收到回傳值的！