Can anyone know the way how to use createEncodedImage method of EncodedImage class in jde 4.5
Thanks and regards,
Vivek Birdi
Here's how you would do it if the Image was a resource file of the application:
byte[] imgData = null;
InputStream in = Application.getApplication().
getClass().getResourceAsStream(imgName);
if(in == null) {
// Handle appropriately
}
try {
int length = in.available();
imgData = new byte[length];
in.read(bytes, 0, length);
} finally {
in.close();
}
if(imgData == null) {
// Handle appropriately
}
EncodedImage encodedImage =
EncodedImage.createEncodedImage(imgData, 0, imgData.length);
You could also pass a String as a parameter to define the MIME type. These are the supported MIME types:
"image/gif"
"image/png"
"image/vnd.wap.wbmp"
"image/jpeg" (supported only on Colour devices)
"image/jpg" (supported only on Colour devices)
"image/pjpeg" (supported only on Colour devices)
"image/bmp"
"image/tiff"
Finally, here's the documentation for 4.5: [EncodedImage Javadocs 4.5][1]
[1]: http://www.blackberry.com/developers/docs/4.5.0api/net/rim/device/api/system/EncodedImage.html#createEncodedImage(byte[], int, int)
Related
I have an Image object which is a jpg picture taken by the camera and I need to create a Bitmap from it.
Is there any way to do it besides using BMPGenerator class? I'm working on a commercial project and I don't think I can use it due to the GPLv3 license.
So far this is the code I have. Can I do something with it?
FileConnection file = (FileConnection) Connector.open("file://" + imagePath, Connector.READ_WRITE);
InputStream is = file.openInputStream();
Image capturedImage = Image.createImage(is);
I tried this but I wasn't able to get the correct filepaht and the image is stuck in null
EncodedImage image = EncodedImage.getEncodedImageResource(filePath);
byte[] array = image.getData();
capturedBitmap = image.getBitmap();
You can use videoControl.getSnapshot(null) and then Bitmap myBitmap = Bitmap.createBitmapFromBytes(raw, 0, raw.length, 1) to get a bitmap from camera.
videoControl is got from player.getControl("VideoControl") and player is got from Manager.createPlayer()
By the way, what kind of Image do you have? If we are talking of EncodedImage, you can just use getBitmap() from it.
Fixed!
Well, almost.
Used the following method but the image is rotated 90 degrees.
Going to fix that with this
public Bitmap loadIconFromSDcard(String imgname){
FileConnection fcon = null;
Bitmap icon = null;
try {
fcon = (FileConnection)Connector.open(imgname, Connector.READ);
if(fcon.exists()) {
byte[] content = new byte[(int) fcon.fileSize()];
int readOffset = 0;
int readBytes = 0;
int bytesToRead = content.length - readOffset;
InputStream is = fcon.openInputStream();
while (bytesToRead > 0) {
readBytes = is.read(content, readOffset, bytesToRead);
if (readBytes < 0) {
break;
}
readOffset += readBytes;
bytesToRead -= readBytes;
}
is.close();
EncodedImage image = EncodedImage.createEncodedImage(content,0,content.length);
icon = image.getBitmap();
}
} catch (Exception e) {
}finally{
// Close the connections
try{ if(fcon != null) fcon.close(); }
catch(Exception e){}
}
return icon;
}
I saw the sample APIas below
public static byte[] compress( byte[] data )
{
try
{
ByteArrayOutputStream baos = new ByteArrayOutputStream();
GZIPOutputStream gzipStream = new GZIPOutputStream( baos, 6, GZIPOutputStream.MAX_LOG2_WINDOW_LENGTH );
gzipStream.write( data );
gzipStream.close();
}
catch(IOException ioe)
{
return null;
}
return baos.toByteArray();
}
But when I tried to compress with a large file with Curve 8900 OS 4.6, I got a "OutOfMemoryError" so I would like to know that how to compress as a chunk small data?
I already tried with this code as below but it doesn't work, compressed file cannot decompress...
file = (FileConnection)Connector.open(_fileOutputPath, Connector.READ_WRITE);
if (!file.exists()) {
file.create();
}
os = file.openOutputStream();
is = FileUtil.getInputStream(_fileInputPath, 0);
int tmpSize = 1024;
byte[] tmp = new byte[tmpSize];
int len = -1;
gzipStream = new GZIPOutputStream( os, 6, GZIPOutputStream.MAX_LOG2_WINDOW_LENGTH );
while((len = is.read(tmp, 0, tmpSize)) != -1) {
gzipStream.write(tmp, 0, len);
}
GZIPOutputStream does not produce a file suitable for use with the gzip command line tool. This is because it doesn't produce the necessary file headers. How did you test decompressing it? You should write a similar Java program that makes use of GZIPInputStream to test, as 'gunzip' is not going to recognize the input.
The problem of the first code sample is that the ByteArrayOutputStream is getting too big for the limited memory of a mobile device.
An option could be to first write to a file (for instance) on SD card.
The second code sample seems fine, but see Michael's answer.
I don’t understand the answer to ”Why does gzip/deflate compressing a small file result in many trailing zeroes?”
(Why does gzip/deflate compressing a small file result in many trailing zeroes?)
How would you go about compressing small amount of data ½-2 Kbyte to minimum size in a .NET-environment?
(Runtime is not an issue for me. Can I trade speed for size? Should I use 3rd party products?
Developer license fees are OK, but runtime license not.)
Any suggestions about how I can improve the code below for:
(a) Higher compression ratio?
(b) More proper use of streams?
Here is the C#-code that needs to be improved:
private static byte[] SerializeAndCompress(MyClass myObject)
{
using (var inStream = new System.IO.MemoryStream())
{
Serializer.Serialize< MyClass >(inStream, myObject); // PROTO-buffer serialization. (Code not included here.)
byte[] gZipBytearray = GZipCompress(inStream);
return gZipBytearray;
}
}
private static Byte[] GZipCompress(MemoryStream inStream)
{
inStream.Position = 0;
byte[] byteArray;
{
using (MemoryStream outStream = new MemoryStream())
{
bool LeaveOutStreamOpen = true;
using (GZipStream compressStream = new GZipStream(outStream,
CompressionMode.Compress, LeaveOutStreamOpen))
{
// Copy the input stream into the compression stream.
// inStream.CopyTo(Compress); TODO: "Uncomment" this line and remove the next one after upgrade to .NET 4 or later.
CopyFromStreamToStream(inStream, compressStream);
}
byteArray = CreateByteArrayFromStream(outStream); // outStream is complete first after compressStream have been closed.
}
}
return byteArray;
}
private static void CopyFromStreamToStream(Stream sourceStream, Stream destinationStream)
{
byte[] buffer = new byte[4096];
int numRead;
while ((numRead = sourceStream.Read(buffer, 0, buffer.Length)) != 0)
{
destinationStream.Write(buffer, 0, numRead);
}
}
private static byte[] CreateByteArrayFromStream(MemoryStream outStream)
{
byte[] byteArray = new byte[outStream.Length];
outStream.Position = 0;
outStream.Read(byteArray, 0, (int)outStream.Length);
return byteArray;
}
From the simulator, this all works.
I'm using wifi on the device as i'm assuming it's the most stable.
The problem occurs when i try to post more than 1.5K of urlencoded data.
If i send less then it's fine.
It seems to hang the .flush command();
It works on a physical 9700, so i'm presuming that it's possibly device specific
In the example below i'm using form variables, but i've also tried posting the content type json, but still had the same issue
I've written a small testapp, and using the main thread so i know that it's not threads getting confused
If anyone has any ideas that would be great.
private String PostEventsTest()
{
String returnValue = "Error";
HttpConnection hc = null;
DataInputStream dis = null;
DataOutputStream dos = null;
StringBuffer messagebuffer = new StringBuffer();
URLEncodedPostData postValuePairs;
try
{
postValuePairs = new URLEncodedPostData(null, false);
postValuePairs.append("DATA",postData);// postData);
hc = (HttpConnection) Connector.open(postURL, Connector.READ_WRITE);
hc.setRequestMethod(HttpConnection.POST);
hc.setRequestProperty("User-Agent", "BlackBerry");
hc.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
hc.setRequestProperty("Content-Length", Integer.toString(postValuePairs.getBytes().length));
//hc.setRequestProperty("Content-Length", Integer.toString(postData.length()));
dos = hc.openDataOutputStream();
dos.write(postValuePairs.getBytes());
dos.flush();
dos.close();
// Retrieve the response back from the servlet
dis = new DataInputStream(hc.openInputStream());
int ch;
// Check the Content-Length first
long len = hc.getLength();
if (len != -1)
{
for (int i = 0; i < len; i++)
if ((ch = dis.read()) != -1)
messagebuffer.append((char) ch);
}
else
{ // if the content-length is not available
while ((ch = dis.read()) != -1)
messagebuffer.append((char) ch);
}
dis.close();
returnValue = "Yahoo";
}
catch (Exception ex)
{
returnValue = ex.toString();
ex.printStackTrace();
}
return returnValue;
}
Instead of data streams you should just use the regular input and output streams. So instead of hc.openDataOutputStream() use hc.openOutputStream(). Data streams are for serializing Java objects to a stream, but you just want to write the raw bytes to the stream -- so a regular outputstream is what you want. Same for reading the response - just use the inputstream returned by hc.openInputStream()
There is a strange problem I've run in using RIM compression API, I can't make it work as it's described in documentation.
If I gzip plain text file using win gzip tool, add gz to resources of blackberry project and in app try to decompress it, there will be infinite loop, gzis.read() never return -1...
try
{
InputStream inputStream = getClass().getResourceAsStream("test.gz");
GZIPInputStream gzis = new GZIPInputStream(inputStream);
StringBuffer sb = new StringBuffer();
char c;
while ((c = (char)gzis.read()) != -1)
{
sb.append(c);
}
String data = sb.toString();
add(new RichTextField(data));
gzis.close();
}
catch(IOException ioe)
{
}
After the compressed content there is repetition of 65535 value in gzis.read(). The only workaround I've found is dumb
while ((c = (char)gzis.read()) != -1 && c != 65535)
But I'm curious what is the reason, what I'm doing wrong, and why 65535?
char is an unsigned, 16-bit data type. -1 cast to a char is 65535.
Change to:
int i;
while ((i = gzis.read()) != -1)
{
sb.append((char)i);
}
And it should work. The example on RIM's API can't possibly work, as no char will ever equal -1.