Всем известно что Android - это платформа с открытым кодом. Как скачать исходники из репозитория я уже писал в отдельной статье. Сегодня я хочу описать простой способ с помощью которого можно просматривать исходный код платформы в Eclipse IDE.
Зачем это нужно ? Во-превых, для того чтобы не открывать онлайн документацию в поисках описания классов и интрефейсов из SDK. Во-вторых, это позволит выполнять отладку по коду SDK и видеть что происходит внутри вызываемых методов.
Итак, если исходники ещё не подключены к среде разработки, то при попытке открыть описание любого класса из Android SDK (Open Declaration - F3)
Самый простой способ подключить исходники - это установить плагин "Android Source" для Eclipse. Актуальную ссылку на апдейт сайт можно найти на Google Code страничке проекта. Обратите внимание, что вам нужен именно Android Sources плагин, поскольку там их несколько.
Теперь берём эту ссылку (сейчас она вот такая http://adt-addons.googlecode.com/svn/trunk/source/com.android.ide.eclipse.source.update/) и добавляем плагин. В Eclipse Indigo это можно сделать через Help > Install New Software.
После установки плагина мы с радостью видим исходный код Android SDK. На текущий момент поддерживаются все версии с 1.5 по 4.0.3. Пользуйтесь - это весьма удобно !
adb shell chmod 777 /data/local/tmp adb install BurritoRoot3.apk adb shell /data/local/tmp/BurritoRoot3.bin --root
HttpClient client = new DefaultHttpClient();
HttpGet request = new HttpGet(url.toString());
HttpResponse response = client.execute(request);
// Pull content stream from response
HttpEntity entity = response.getEntity();
InputStream inputStream = entity.getContent();
ByteArrayOutputStream content = new ByteArrayOutputStream();
// Read response into a buffered stream
int readBytes = 0;
byte[] buffer = new byte[BUFFER_SIZE];
while ((readBytes = inputStream.read(buffer)) != -1) {
content.write(buffer, 0, readBytes);
}
String plain = new String(content.toByteArray());
JSONArray data = new JSONArray(plain);
Отточеная до автоматизма тривиальность не предвещала никаких сложностей. Но увы, как это часто бывает всё не так просто как кажется на первый взгляд.for (int i = 0; i < response.length(); i++) {
JSONObject item = response.getJSONObject(i).getJSONObject("item");
Point point = Point.fromJson(item);
ContentValues values = new ContentValues();
values.put(KEY_POINT_ID, object.getId());
values.put(KEY_POINT_NAME, object.getName());
values.put(KEY_POINT_LAT, object.getLat());
values.put(KEY_POINT_LON, object.getLon());
values.put(KEY_POINT_TYPE, object.getType());
values.put(KEY_POINT_UPDATE_TIME, object.getUpdateTime());
db.insert(TABLE_POINT, null, values);
}
Запускаем - замечательно, всё работает как в сказке с первой попытки. Только вот как-то долго... Прошло минуты две, а обработаны меньше четверти данных... Вряд-ли у пользователей хватит терпения ждать 10 минут, пока загрузится приложение. Да и как-то не гуманно это что-ли, так что начинаем анализировать на что тратится так много времени. Для этого под Android есть специальная тулза traceview и Debug.startMethodTracing / Debug.stopMethodTracing в помощь. Важный момент - размер .trace - файла по умолчанию 8 Мб, что исчерпывается быстро. Поэтому я установил его побольше и ограничить импорт выборкой одной страницы в 582 записи. Оборачиваем интересующий нас код вот так:
Debug.startMethodTracing("myapp", 20 * 1024 * 1024);
// ... сдесь идёт код импорта данных ...
Debug.stopMethodTracing();
Снова запускаем и по завершению выполнения находим myapp.trace в корне /sdcard на телефоне. Теперь для анализа "сырых" данных из этого файла запускаем:
traceview <путь-к-папке>/myapp
do {
HttpClient client = new DefaultHttpClient();
HttpGet request = new HttpGet(url.toString());
HttpResponse response = client.execute(request);
// Pull content stream from response
HttpEntity entity = response.getEntity();
InputStream inputStream = entity.getContent();
JsonFactory f = new JsonFactory();
JsonParser jp = f.createJsonParser(inputStream);
if (jp.nextToken() == JsonToken.VALUE_NULL) {
break;
}
while (jp.nextToken() != JsonToken.END_ARRAY) {
Point point = null;
while (jp.nextToken() != JsonToken.END_OBJECT) {
String fieldname = jp.getCurrentName();
jp.nextToken(); // move to value, or
// START_OBJECT/START_ARRAY
if ("item".equals(fieldname)) { // contains an object
point = pointFromJson(jp);
} else {
throw new IllegalStateException("Unrecognized field '" + fieldname + "'!");
}
}
if (point != null) {
db.getPointDao().create(point);
}
}
jp.close();
А, вот как изменилась статистика:
// Prepare insert statement.
SQLiteStatement insert = db.compileStatement(INSERT_STATEMENT);
db.beginTransaction();
try {
while (scanner.hasNextLine()) {
String line = scanner.nextLine();
String[] columns = line.split(";");
try {
if (columns.length == 7) {
insert.clearBindings();
// Important ! Order of the fields in the statement
// should be the same like in CSV input.
for (int i = 0; i < 7; i++) {
insert.bindString(i + 1, columns[i]);
}
insert.execute();
result++;
}
} catch (Exception e) {
Log.e("AppTrack", Log.getStackTraceString(e));
}
}
db.setTransactionSuccessful();
} finally {
db.endTransaction();
}
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
<soapenv:Header/>
<soapenv:Body>
<tem:ApproveSession>
<tem:token>?</tem:token>
</tem:ApproveSession>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
<soapenv:Header/>
<soapenv:Body>
<tem:ApproveSession>
<tem:token>token${=context.getProperty("ThreadIndex")+1}</tem:token>
</tem:ApproveSession>
</soapenv:Body>
</soapenv:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="39ef48c3-d7ca-4947-9644-4146e9d6c1ec" Name="WixExeSetup" Language="1033"
Version="1.0.0.0" Manufacturer="WixExeSetup"
UpgradeCode="d69d6b38-b736-44e8-98b8-d3fded2545da">
<Package InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
<UIRef Id="WixUI_Minimal"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="WixExeSetup">
<Component Id="license.txt" Guid="177b4634-0246-49db-89a9-c3b539ebd93d">
<File Id="license.txt" Source=".\license.txt" KeyPath="no" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="ProductFeature" Title="WixExeSetup" Level="1">
<ComponentRef Id="license.txt" />
</Feature>
</Product>
</Wix>
Это могло быть оставлено незамеченным, если бы мы не решили использовать регулярные выражения из TR1 которые появились в VC++ c выходом Visual Studio 2008 SP1.
В следствии, приложение начало выдавать ошибку при запуске в тестовой среде.
Сначала оказалось, что при инсталяции нашего приложения, мы использовали инсталяционный модуль Microsoft_VC90_CRT_x86.msm предыдущей версии 9.0.21022.8. Но после того как это было исправлено и мы добавили модуль версии 9.0.30729.1 приложение перестало запускаться вовсе. В Event Viewer появились ошибки о том что не найдена сборка Microsoft.VC90.CRT версии 9.0.21022.8. Проблема оказалась в том, что в манифесте приложения указана RTM (9.0.21022.8) версия Runtime компонент.
В результате поиска решения, было найдено два варианта:
Как известно, в последней версии .Net Framerork Microsoft предлагает два ORM решения: LINQ to SQL и ADO.NET Entity Framework. Первое появилось с выходом .Net 3.5 и Visual Studio 2008, в то время как ADO.NET Entity Framework вошёл в .NET 3.5 SP1 с поддержкой в Visual Studio 2008 SP1.
Но, несмотря на то, что ADO.NET Entity Framework появился позже LINQ to SQL и в функциональном плане пока уступает, он развивается более динамично и уже в следующей версии фреймворка будет значительно расширен новыми фитчами.
Более того, Microsoft уже выпустила первую версию шаблонов Visual Studio 2010 для миграции метаданных LINQ to SQL ( .dbml ) в метаданные ADO.NET Entity Framework ( .edmx ). Что подтверждает намерения Microsoft в ближайших версиях отказаться от LINQ to SQL в пользу ADO.NET Entity Framework.
Это вовсе не означает, что в один прекрасный момент, всё то что было написано с использованием LINQ to SQL перестанет работать, однако может оказаться серьёзным препядствием для миграции приложения на новые версии .Net Framerork. С этой точки зрения ADO.NET Entity Framework является более привлекательным для использования в реальных Enterprise проектах.