Всем здравствуйте! У меня проблема.. Мне нужно считывать данные с конца файла, но функция skip слишком долго работает. Делаю я это так...


Приходится ждать несколько минут... Как сделать так, чтобы можно было быстро начать читать с конца файла? Есть ли какие-нибудь средства произвольного доступа к файлу?

Нужно порезать файл на кусочки известной длины и сразу открывать нужный кусок.

Подругому нельзя? Есть ли классы произвольного доступа к файлам?
И если резать, то как? Программно или перед переносом на телефон вручную?

Конечно, для реализации getResourceAsStream() нужно иметь произвольный доступ в файле и уметь раскрывать ZIP. Но в стандартном API этого нет. В J2ME-читалках книжки обычно режут кусками 16K. Программу для нарезки можно найти в интернете или написать самому.

Тоесть резать программно? закидываю на телефон целый файл и джава прогой режу его и помещаю в память? так чтоли? можете скинуть ссылку на какойнить пример?

Сталкивался с такой же проблемой. Решена она была так - взял код метода InputStream.skipBytes() из JDK, написал в своем классе точно такой же, но с увеличенным размером буфера:


Размер буфера был определен эмпирическим путем. У меня файлы используются 700-1000Кб, поэтому размер буфера в 20 Кб оказался оптимальным с точки зрения затрачиваемой памяти и получаемого быстродействия.

Я уже у себя так делал... но всеровно спасибо! Просто думал может есть способ другой... какогонит произвольного доступа... без постонного считывания в массив. А как вернуть поток на начало?

Как нибудь можно всётаки перемещаца на начало файла с помощью skip или другими средствами БЕЗ нового открытия потока на файл, как показано ниже:

Ну неужели никто не знает и не сталкивался с этим?! :( Помогите плиз, очень надо...

А в J2ME нет класса RandomAccessFile?

Это сообщение отредактировал(а) Дрон - 4.6.2008, 15:06

Нет. Все операции с файлом потоковые и односторонние.

Добавлено через 4 минуты и 20 секунд
Brodyaga, можно попробовать сделать mark() на InputStream в позиции, куда надо будет откатиться, а в нужный момент вызвать reset(). Правда, в этом случае нужно быть готовым получить IOException, если в твоей реализации JSR-75 mark() / reset() не поддерживается.

Добавлено через 8 минут и 30 секунд
А можно даже и не ждать IOException, а просто спросить у потока: InputStream.markSupported(). Если вернет true - счастье, можно использовать подход, про который я выше написал. Если false - увы, придется открывать новый поток каждый раз.

Кстати, а что ты имеешь против открытия нового потока? Считаешь, что слишком накладная операция? Не думаю, что настолько, чтобы бояться лишний раз открыть поток  

Новый поток к файлу - новый запрос "Разрешить читать / писать данные из файла?"



Это сообщение отредактировал(а) eugine_s - 4.6.2008, 15:17

Если политика безопасности на устройстве не дает разрешить чтение до конца сессии или от первого обращения до удаления, то да, ты прав. А так как мы должны думать о переносимости между устройствами, и в общем случае запрос на разрешение может появляться при каждом обращении, то ты и подавно прав   

Поэтому вижу только один выход. Проверить, поддерживается ли mark()-reset() на файловом потоке, если поддерживается - радоваться и использовать. Если нет - можно запесочить своего наследника от InputStream, который будет поддерживать mark() - reset() за счет кэширования считанных данных. Увы, для случая, если мы находимся в конце файла, мы сможем откатиться в начало, только если весь файл вычитать в память. Для больших файлов не решение, но если же нужно откатываться только в пределах разумного диапазона, например, десяток-другой килобайт, то это поможет.

В том то и дело что нет...


Как раз таки настолько... Если бы было не настолько я бы не искал решения без новых коннекций..



Мидлет подписан... Тут дело в том что эта операция очень ресурсоёмкая



А от чего зависит возможность поддержки потоком mark-reset ? Из разговора я понял что не все потоки могут его поддерживать? какие могут, а какие нет?

Почему ты так думаешь? Делал какие-то конкретные замеры? Какие именно ресурсы так требует эта безобидная операция?



От конкретной реализации JSR-75. В принципе, для файлов не составляет труда реализовать mark() на неограниченный размер и reset() без всяких буферов в памяти, просто используя платформенный seek(), - как раз то, что тебе нужно. Но вот реализовано это или нет - точно сказать нельзя, надо проверять в каждом конкретном случае. Для этого и придумали InputStream.markSupported().

Это сообщение отредактировал(а) Dummy - 5.6.2008, 09:04