Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Он живее всех живиых, его фиг убьешь!
сейчас сам разбираюсь с FMDB, мне кажется полезнее было бы в статье описать оссобенность работы с данной библиотекой и разные варианты использования
т.к. создать проект и подцепить к нему базу — самое простое, проблемы начинаются дальше
т.к. создать проект и подцепить к нему базу — самое простое, проблемы начинаются дальше
Согласен. Одна из тонкостей которая нигде мне не встречалась в статьях и документации это то, что все параметры которые передаются в запрос должны иметь строковый тип. Я долго не мог понять почему приложение валится пока не разрыл исходники и не сконвертировал NSInteger в NSString
Это ваш холодильник?
>Если будут восхищенные отзывы то я эту тему буду продолжать.
Даже если их не будет (новички в основном RO) я считаю всё равно стоит продолжать, чем больше качественной литературы тем однозначно лучше.
Даже если их не будет (новички в основном RO) я считаю всё равно стоит продолжать, чем больше качественной литературы тем однозначно лучше.
1. Не только. Например, у автора на скринах версия 4.4.1, а в MAS — 4.5.2
а в MAS — 4.5.2Это та, из которой выпилили поддержку iPhone 3G?
Не было никакой «поддержки iPhone 3G». Выпилили симулятор для iOS 4.
blog.whatsapp.com/index.php/2012/12/iphone3g/
Apple has stopped supporting old iOS versions and old iPhones in their most recent version 4.5 of Xcode
А можно ссылочку на Apple, а не на разработчика приложения, пользователи которого, видимо, достали его письмами «тормозит на 3G, почините!»?
А можно ссылочку на AppleПожалуйста: www.apple.com :)
This version of Xcode does not generate armv6 binaries.
The minimum deployment target is iOS 4.3.
Не вижу там «The minimum deployment device is iPhone 3GS»
Казалось бы, причём здесь iPhone 3GS…
Ну вы же сами заявили, что в Xcode 4.5 якобы убрали поддержку iPhone 3G. Следующая модель — iPhone 3GS.
Чёрт, вы меня запутали.
Процитирую ещё раз:
У iPhone 3GS armv7.
Имхо, это недоработка Эппла, что нельзя загружать в App Store бинарники для разных моделей устройств и разных версий ОС.
Универсальное приложение сейчас должно поддерживать все существующие версии iOS и все выпущенные аппараты одновременно — это и для программиста дополнительная работа, и для конечного пользователя лишний объём данных.
Процитирую ещё раз:
This version of Xcode does not generate armv6 binaries.
У iPhone 3GS armv7.
Имхо, это недоработка Эппла, что нельзя загружать в App Store бинарники для разных моделей устройств и разных версий ОС.
Универсальное приложение сейчас должно поддерживать все существующие версии iOS и все выпущенные аппараты одновременно — это и для программиста дополнительная работа, и для конечного пользователя лишний объём данных.
Ага, вы добавили в свой комментарий строку про отсутствие поддержки armv6. Вот теперь я согласен. Поддержка armv7 появилась в 3GS, в котором стоит S5L8920
1. Я было хотел скачать с AppStore но пока не могу открыть карту (приват до 15-го не выпускает Visa Internet) чтобы заполнить соотв. информацию для окончания регистрации Apple ID для того чтобы можно было качать приложения с AppStore
2. А вот тут спасибо, даже не знал что такое есть!
2. А вот тут спасибо, даже не знал что такое есть!
Так, критикую/советую:
1) ARC как раз таки есть под iOS, и это НЕ GC, не путайте:) И, судя по Вашему коду, я Вам настоятельно рекомендую его включить;)
2) заместо создания TableView и блаблабла вы могли поступить гораздо проще, создав UITableViewController в Storyboard-е (который, во первых, автоматически связывает dataSource и delegate с File owner-ом, а так же позволяет делать static cells для интерфейсов)
3) даже по Вашему коду, вы унаследовали VC от UIViewController, а должны были от UIViewController<UITableViewDelegate, UITableViewDataSource> (если не знаете, что это такое я тут пишу, то почитайте про протоколы:))
4) Так же при использовании storyboard отпадает необходимость в проверке cell == nil в cellForRowAtIndexPath, т.к. dequeueReusableCellWithIdentifier может возвращать ячейки, созданные в этом самом Storyboard, визуально. Тоже очень рекомендую;)
5) FMDB есть в Cocoapods, который избавляет Вас от ручного git clone blablabla
P.S. надеюсь пока писал этот развёрнутый комментарий никто ещё не успел все эти пункты осветить)
1) ARC как раз таки есть под iOS, и это НЕ GC, не путайте:) И, судя по Вашему коду, я Вам настоятельно рекомендую его включить;)
2) заместо создания TableView и блаблабла вы могли поступить гораздо проще, создав UITableViewController в Storyboard-е (который, во первых, автоматически связывает dataSource и delegate с File owner-ом, а так же позволяет делать static cells для интерфейсов)
3) даже по Вашему коду, вы унаследовали VC от UIViewController, а должны были от UIViewController<UITableViewDelegate, UITableViewDataSource> (если не знаете, что это такое я тут пишу, то почитайте про протоколы:))
4) Так же при использовании storyboard отпадает необходимость в проверке cell == nil в cellForRowAtIndexPath, т.к. dequeueReusableCellWithIdentifier может возвращать ячейки, созданные в этом самом Storyboard, визуально. Тоже очень рекомендую;)
5) FMDB есть в Cocoapods, который избавляет Вас от ручного git clone blablabla
P.S. надеюсь пока писал этот развёрнутый комментарий никто ещё не успел все эти пункты осветить)
Нихило вы меня щя пригрузили внеклассным чтением)) По делу могу ответить только на 2-й пункт: я сделал это умышленно чтобы показать как связывается TableView с контроллером, лично у меня на то чтобы это понять ушел не один час. Ну а по остальным пунктам благодарствую, буду изучать.
Да, outlet-ы даются не сразу, сам так же «зависал» при попытке что-то соединить (было непривычно после Flex-а, в котором это делалось Binding-ами)
Кстати, должен заметить, по 3му пункту, что я имел ввиду по конкретно Вашему случаю. В остальных же, наследуйтесь от UITalbeVIewController, если Ваш вид представляет из себя только UITableVIew. Вообще, тут есть хитрость:
UITableViewController не позволяет View быть ничем другим, кроме как UITableVIew, т.е. у Вас не получится сделать UITableView на половину экрана, а в остальной половине сделать кнопку, к примеру. Но при этом это даёт мощнейший механизм Static Table View Cells + Grouped Cells, который все используют для интерфейсов (самый ближайший пример — это Settings.app, т.е. обычные настройки)
Ну и вообще, не стесняйтесь, обращайтесь, спрашивайте, я готов помогать\разъяснять в меру своего свободного времени) скайп есть в профайле, если что:)
Кстати, должен заметить, по 3му пункту, что я имел ввиду по конкретно Вашему случаю. В остальных же, наследуйтесь от UITalbeVIewController, если Ваш вид представляет из себя только UITableVIew. Вообще, тут есть хитрость:
UITableViewController не позволяет View быть ничем другим, кроме как UITableVIew, т.е. у Вас не получится сделать UITableView на половину экрана, а в остальной половине сделать кнопку, к примеру. Но при этом это даёт мощнейший механизм Static Table View Cells + Grouped Cells, который все используют для интерфейсов (самый ближайший пример — это Settings.app, т.е. обычные настройки)
Ну и вообще, не стесняйтесь, обращайтесь, спрашивайте, я готов помогать\разъяснять в меру своего свободного времени) скайп есть в профайле, если что:)
Теперь понял, что вы имели ввиду в пункте 3. Тут столько всего мне уже посоветовали что бессонные ночи на ближайшую неделю мне обеспечены. В общем спасибо. А скайп ваш запомню на всякий случай)
static table view cells и grouped cells можно прекрасно использовать и в стандартном uitableview вставленном в uiviewcontroller.
Но не при визуальном редактировании в Storyboard
unholy прав, можно и в обычной uitableview при редактировании Storyboard. Я не уверен насчет таблиц со стилем Grouped, но в Plan можно создавать прототипы cell'ов.
5) FMDB есть в Cocoapods, который избавляет Вас от ручного git clone blablabla
Да, cocoapods уже чуть ли не стандарт для iOS разработки, по-крайней мере для меня точно.
А git и все-все-все для Mac OS есть в homebrew.
>Здесь же сразу идем на вкладку “Build Settings” и ставим “Objective-C Automatic Reference Counting” в “No”, т.к. в iOS нет сборщика мусора.
Что? Это не сборщик мусора, это совсем другое и оно прекрасно работает на iOS! Используйте!
Что? Это не сборщик мусора, это совсем другое и оно прекрасно работает на iOS! Используйте!
Спасибо, понял)
И еще исходные коды с конференций Apple поизучайте, там много примеров для начинающих: developer.apple.com/wwdc/
«Objective-C для трактористов» — выстрелит, однозначно!
Просто как то, таких примеров полно на той же linda.com. И к sqlite можно напрямую обращаться мимо CoreData.
Может кто-нибудь популярно объяснить преимущества FMDB перед CoreData?
единственное преимущество если у меня есть здоровая таблица которую я откуда то взял и мне незачем создавать модель, маппинг и прочее только ради того чтобы оттуда выдернуть инфу.
например у меня есть sqlite3 база данных со всеми городами мира, там порядка 300000 записей только городов и sqlite3 напрямую вызовы самый быстрый путь чтото оттуда получить
например у меня есть sqlite3 база данных со всеми городами мира, там порядка 300000 записей только городов и sqlite3 напрямую вызовы самый быстрый путь чтото оттуда получить
разные use cases очень
зачем вообще это было писать если это описано в документации эппл и на гитхабе у FMDB?
в .h файле не принято определять переменные которые используются только в .m файле, повторите секцию interface в .m
затем переменные с подчеркиванием в интерфейсе не рекомендуется использоваться так как подчеркнутые переменные удел внутренних классов apple. да и не понятно к чему вообще это подчеркивание.
ну и плюс этот код не соберется так как проект создавался с ARC, а в тексте программы явно видно release
в .h файле не принято определять переменные которые используются только в .m файле, повторите секцию interface в .m
затем переменные с подчеркиванием в интерфейсе не рекомендуется использоваться так как подчеркнутые переменные удел внутренних классов apple. да и не понятно к чему вообще это подчеркивание.
ну и плюс этот код не соберется так как проект создавался с ARC, а в тексте программы явно видно release
так как подчеркнутые переменные удел внутренних классов apple
Это, кстати, давно уже не так. Эппл смирились с тем, что комьюнити выбрало такую конвенцию для инстанс мемберов. В последних версиях clang для
@property даже не нужен @syntesize, и @syntesize name = _name; будет сгенерировано компилятором автоматически.ну и плюс этот код не соберется так как проект создавался с ARC, а в тексте программы явно видно release
Самое странное, что проект собирается и успешно работает и с ARC и без него
>да и не понятно к чему вообще это подчеркивание.
очень даже понятно, чтоб property с ivar'ами визуально не путать.
очень даже понятно, чтоб property с ivar'ами визуально не путать.
Я бы только последовательность команд в методе "- (void)viewDidUnload" поменял бы местами. Мало ли что там этот super уже выгрузить успеет.
Это как html теги — alloc и release надёжнее делать вложено, а не пересекать друг друга для наглядности и предсказуемости.
Это как html теги — alloc и release надёжнее делать вложено, а не пересекать друг друга для наглядности и предсказуемости.
Статья безусловно хороша для начинающих. Но зачем вот писать такое:
Первое что необходимо сделать это купить себе мак. Конечно есть еще вариант установить себе хакинтош и его отбрасывать не стоит, это достойная альтернатива, если не возникнет проблем с совместимостью железа.
IDE и ее сопутствующий инструментарий впечатляет. Ну реально, вывести таблицу вообще можно без проблем.
Чудеса прямо!
Сталкивался с FMDB, очень легковесная штуковина как показалась на первый взгляд. Вопрос к автору: «Почему выбрали sqlite, а не таблички .plist»?
Я не вникал во все способы зранения данных (не подозревал до сегодняшнего дня о существовании plist и Core Data), просто когда засел за Xcode вспомнил, что у нас на фирме коллега использовал для одного из приложений sqlite, от этого и начал отталкиваться.
Почему спрашиваю, многие используют их как заменялки бд, интересно о выгоде/проигрыше по сравнению с небольшой бд на sqlite. Приложение на сколько объемные данные хранила если не секрет?, просто некоторые, бд, например для логов используют, вроде бы совсем небольшая информация. Относительно конечно.
Я вот все ровно не совсем понял зачем создавать sqlite3 базу в ручную и использовать всякие стороние библиотеки, если есть Core Data. Там же все удобно сделанно и очень классно интегрируется с UITableViewController. Вы можете создать проект из шаблона Master-Detail Application и посомтреть как там все сделанно.
Использование Core Data предоставляет удобный графический интерфейс для доступа к таблицам и полям.
По поводу вопроса «имею готовую таблицу с 30000000000 готовых записей… » — Вам ничто не мешает создать готовую пустую таблицу в Core Data с нужными полями, а потом через ту же консольную утилиту sqlite3 заполнить ее данными из Вашей готовой таблицы.
Использование Core Data предоставляет удобный графический интерфейс для доступа к таблицам и полям.
По поводу вопроса «имею готовую таблицу с 30000000000 готовых записей… » — Вам ничто не мешает создать готовую пустую таблицу в Core Data с нужными полями, а потом через ту же консольную утилиту sqlite3 заполнить ее данными из Вашей готовой таблицы.
Статья про iOS, которая пробудила желание снова поковыряться в мобильной разработке. Ждемс продолжения с блекджеком и ш усложненным storyboard и возможностью редактирования записей.
А у меня вопрос.
В viewDidUnload вы загружаете все данные из базы массив. В cellForRowAtIndexPath выбираете из массива нужный для отображения элемент.
Если база большая, и пользователь не будет просматривать/прокручивать всю таблицу, то не нужно грузить в viewDidUnload всю базу в массив.
Может имеет смысл загружать из базы данные только по мере необходимости (в cellForRowAtIndexPath), а в viewDidUnload получить только количество записей, чтобы использовать это количество в numberOfRowsInSection?
В viewDidUnload вы загружаете все данные из базы массив. В cellForRowAtIndexPath выбираете из массива нужный для отображения элемент.
Если база большая, и пользователь не будет просматривать/прокручивать всю таблицу, то не нужно грузить в viewDidUnload всю базу в массив.
Может имеет смысл загружать из базы данные только по мере необходимости (в cellForRowAtIndexPath), а в viewDidUnload получить только количество записей, чтобы использовать это количество в numberOfRowsInSection?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
UITableView+sqlite3 для самых маленьких