7 заметок с тегом мобильная разработка

Ctrl + ↑ Позднее

Давно я не писал о кодерском...

На прошлой неделе тестировщик показал мне баг в нашем iOS-приложении: после ввода текста интерфейс должен был переходить в другой режим, но ничего не происходило. Повторялось это стабильно. «Ок, посмотрю», — сказал я и пошёл фиксить на своём устройстве.

Попытался воспроизвести — никак. Пошёл за девайсом, на котором баг воспроизвёлся, но после перезапуска на нём всё заработало правильно. Странно. Попробовал ещё несколько раз — без толку. Полез смотреть код, перепроверил несколько раз всю логику — вроде всё верно. Потратил больше часа и не смог найти проблему. «Как же так, я же только что видел, что он воспроизводится!» Вспомнив про фазу луны, решил запустить в последний раз, и — ура! — проблема повторилась. Начал дебажить. Смотрю — в коде есть метод:

- (BOOL)isEnabled {
    return (_text);
}

Здесь _text — это строка, и она содержит правильный текст. Адрес у неё 0x15f11800, а метод возвращает NO.

Конечно, я знал, что так неявно возвращать BOOL не нужно, и сам так никогда не пишу. Но в чужом коде глаз за такое не зацепился. Написал тест:

BOOL BOOLCast() {
    long long address = 0x15f11800;
    return address;
}

int main(int argc, const char * argv[]) {
    NSLog(@"\%@\n", BOOLCast() ? @"YES" : @"NO");
    return 0;
}

Выводит:

NO

Xcode не выдаёт никаких ворнингов, анализатор — тоже. Забавно, что такая конструкция сработает правильно:

if (_text)

Дело в том, что в Objective-C тип BOOL объявлен как signed char, поэтому адрес 0x15f11800 обрезается и приводится к нулю. Другими словами, 0x15f11800 делится нацело на размер BOOL. То есть баг воспроизводится каждый раз, когда последний байт адреса оказывается нулевым.

368 121 856 / 256 = 1 437 976

Коллега сказал, что в C++ такая штука будет работать правильно с типом bool, так как инициализация происходит по-другому. Проверяем:

#include <iostream>

typedef signed char BOOL;

bool boolCast(void) {
    long long i = 0x15f11800;
    return i;
}

BOOL BOOLCast(void) {
    long long i = 0x15f11800;
    return i;
}

int main(int argc, const char * argv[]) {
    printf("bool: %d\nBOOL: %d\n", boolCast(), BOOLCast());
    return 0;
}

bool: 1
BOOL: 0

В Objective-C тоже есть тип bool, и результат аналогичен:

#import <Foundation/Foundation.h>

bool boolCast() {
    long long i = 0x15f11800;
    return i;
}

BOOL BOOLCast() {
    long long i = 0x15f11800;
    return i;
}

int main(int argc, const char * argv[]) {
    NSLog(@"\nbool: %d\nBOOL: %d\n", boolCast(), BOOLCast());
    return 0;
}

bool: 1
BOOL: 0

Однако Apple советует везде использовать BOOL. В любом случае, чтобы не зависеть от платформы, языка и архитектуры, лучше явно сравнивать с nil. Лишние символы спасут от непонятных багов:

return _text != nil;

Ну а как же Свифт? Свифт — молодец:

А теперь представьте, сколько подобного кода может быть у вас :-)

c++   ios   objective-c   swift   баг   мобильная разработка   программирование

Прошло почти полгода с момента запуска WeekDefiner — моего первого приложения в App Store. Спасибо всем, кто качал сам и советовал качать друзьям!

За всё время существования WeekDefiner был скачан 148 раз с ожидаемыми всплесками в апреле (появление в App Store) и сентябре (начало учебного года). Вот график по неделям:

Теперь я начинаю делать версию 2.0, и вот почему:

  1. Меня радуют показатели скачиваний, особенно с учётом того, что WeekDefiner никак не продвигался, кроме двух ссылок на приложение в Twitter и ВК.
  2. Выход iOS 7, подразумевающий как полный редизайн, так и новые интересные технологии.
  3. За последние полгода я узнал много нового как в программировании, так и в дизайне, типографике, управлении проектами и других вещах. Теперь WeekDefiner 1.0 мне кажется плохо написанным, неудобным и некрасивым.
  4. Снова хочу сделать приложение по принципу «от и до»: буду сам проектировать экраны, рисовать иконку, писать код, тестировать, анализировать и продвигать.

Думаю, что на разработку уйдёт около трёх месяцев. После релиза обязательно выложу dev story.

P. S. Так как последнее время я занимался разработкой под Android, то, возможно, созрею и для Google Play версии. Естественно, если вы захотите :-)

devstory   ios   iphone   weekdefiner   дизайн   мобильная разработка

Так получилось, что теперь у меня есть опыт разработки под обе лидирующие мобильные платформы — iOS и Android. Неудивительно, что процесс программирования под эти операционные системы похож — сказывается мобильная специфика. Однако пересесть с iOS на Android оказалось тяжело.

Сначала я хотел написать о технических деталях, например, более сложном создании UI, который в Android верстается руками через xml-файлы. Или о неудобном подцеплении обработчиков кнопок. Или о механизмах персистентности. Или о сложной работе с анимацией... Потом я понял, что некоторые вещи в Android реально круты, например, Intents или Content Providers. Или адаптеры и курсоры для таблиц. Далее пришло понимание, что с технической точки зрения обе платформы имеют свои преимущества и недостатки, и кому-то, скорее всего, ближе подход Google, а кому-то, как мне, всё равно решения от Apple кажутся более логичными.

Другими словами, вроде всё хорошо, но почему-то всё равно остаётся ощущение, что разрабатывать под Android тяжелее и не так увлекательно. Разгадка кроется на поверхности — во всём виноваты инструменты разработки.

Первое, что вызывает недоумение (и культурный шок пользователя OS X) — феерическая корявость Eclipse. Xcode же, наоборот, поражает своей мощью, простотой и логичностью. Visual Studio может поспорить с ним в плане продвинутости, но, на мой взгляд, нет инструмента удобнее, чем Xcode. То же самое можно сказать и про симуляторы/эмуляторы, документацию, примеры, процесс отладки, настройки проекта, профилирование — во всех этих компонентах Apple далеко впереди.

Надеюсь, что Google исправит ситуацию, тем более что уже давно обещают выпуск Android Studio на базе IntelliJ IDEA. Пока же кодинг под Android напоминает неравную борьбу с Eclipse и ADT, после которой написать что-нибудь под iPhone — сплошное удовольствие.

android   apple   ios   мобильная разработка   работа