Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #3060 > unrolled thread

Android: create drawable from path

Back to article view | Back to comp.lang.java.programmer

Contents

  Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-14 18:37 +0100
    Re: Android: create drawable from path Lew <lew@lewscanon.com> - 2011-04-14 12:06 -0700
      Re: Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-14 21:32 +0100
        Re: Android: create drawable from path Lew <noone@lewscanon.com> - 2011-04-14 18:32 -0400
          Re: Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-15 00:52 +0100
            Re: Android: create drawable from path Patricia Shanahan <pats@acm.org> - 2011-04-14 17:28 -0700
              Re: Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-15 02:20 +0100
                Re: Android: create drawable from path Patricia Shanahan <pats@acm.org> - 2011-04-14 21:20 -0700
                  Re: Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-04-15 11:38 +0100
                    Re: Android: create drawable from path Patricia Shanahan <pats@acm.org> - 2011-04-15 09:25 -0700
                      Re: Android: create drawable from path Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-04 18:29 +0100
                        Re: Android: create drawable from path markspace <-@.> - 2011-05-04 11:24 -0700
                        Re: Android: create drawable from path Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-04 20:27 +0200
                        Re: Android: create drawable from path Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-05 09:39 +0100
            Re: Android: create drawable from path Lew <noone@lewscanon.com> - 2011-04-15 07:27 -0400

#3060 — Android: create drawable from path

For some reason d=null when creating a drawable from coverArtURLStr, 
which is the full http path to the resource on the LAN.
Anything obvious wrong? It's a path to a .png
[I can access the LAN OK, and Data.defaultCoverArt works fine]

public static void updateCoverArt(String coverArtURLStr)
     {
     	String coverArtURL = coverArtURLStr;
     	Drawable d;
     	
     	if (coverArtURL.equals(""))
     		d = Data.defaultCoverArt;
     	else    		
     		d = Drawable.createFromPath(coverArtURL);
     	
     	Data.coverArtIV.setImageDrawable(d);
     }


-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [next] | [standalone]

#3061

On Apr 14, 1:37 pm, Dirk Bruere at NeoPax <dirk.bru...@gmail.com>
wrote:
> For some reason d=null when creating a drawable from coverArtURLStr,
> which is the full http path to the resource on the LAN.
>

Are you certain that value is what the method sees?

> Anything obvious wrong? It's a path to a .png
> [I can access the LAN OK, and Data.defaultCoverArt works fine]
>
> public static void updateCoverArt(String coverArtURLStr)
>      {
>         String coverArtURL = coverArtURLStr;
>

Why the extra 'String' assignment?

What is the *actual* value of 'coverArtURLStr' at this point when you
have the problem?

>         Drawable d;
>
>         if (coverArtURL.equals(""))
>                 d = Data.defaultCoverArt;
>         else                    
>                 d = Drawable.createFromPath(coverArtURL);
>

The value of 'd' at this point when you have the problem is 'null',
you say.

>         Data.coverArtIV.setImageDrawable(d);
>      }
>

When you say "I can access the LAN OK", that may or may not bear on
whether your program can access the LAN when you're running your
test.  There's insufficient information in your post for us to know.

Since you have not provided an SSCCE there's little likelihood we can
debug your problem.  On the face of it the'createFromPath()' method is
unable to access the actual URL string you're giving it, a datum you
have omitted from your problem statement.

Provide an SSCCE, please.

--
Lew

[toc] | [prev] | [next] | [standalone]

#3062

On 14/04/2011 20:06, Lew wrote:
> On Apr 14, 1:37 pm, Dirk Bruere at NeoPax<dirk.bru...@gmail.com>
> wrote:
>> For some reason d=null when creating a drawable from coverArtURLStr,
>> which is the full http path to the resource on the LAN.
>>
>
> Are you certain that value is what the method sees?
>
>> Anything obvious wrong? It's a path to a .png
>> [I can access the LAN OK, and Data.defaultCoverArt works fine]
>>
>> public static void updateCoverArt(String coverArtURLStr)
>>       {
>>          String coverArtURL = coverArtURLStr;
>>
>
> Why the extra 'String' assignment?
>
> What is the *actual* value of 'coverArtURLStr' at this point when you
> have the problem?
>
>>          Drawable d;
>>
>>          if (coverArtURL.equals(""))
>>                  d = Data.defaultCoverArt;
>>          else
>>                  d = Drawable.createFromPath(coverArtURL);
>>
>
> The value of 'd' at this point when you have the problem is 'null',
> you say.
>
>>          Data.coverArtIV.setImageDrawable(d);
>>       }
>>
>
> When you say "I can access the LAN OK", that may or may not bear on
> whether your program can access the LAN when you're running your
> test.  There's insufficient information in your post for us to know.
>
> Since you have not provided an SSCCE there's little likelihood we can
> debug your problem.  On the face of it the'createFromPath()' method is
> unable to access the actual URL string you're giving it, a datum you
> have omitted from your problem statement.
>
> Provide an SSCCE, please.
>
> --
> Lew
>

Actually, there is enough information.
It seems that
Drawable.createFromPath(coverArtURL);

doesn't like it if the path is http:\\...
I've just got it to work.
I'll post the code tomorrow for reference

-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [prev] | [next] | [standalone]

#3064

On 04/14/2011 04:32 PM, Dirk Bruere at NeoPax wrote:
> On 14/04/2011 20:06, Lew wrote:
>> On Apr 14, 1:37 pm, Dirk Bruere at NeoPax<dirk.bru...@gmail.com>
>> wrote:
>>> For some reason d=null when creating a drawable from coverArtURLStr,
>>> which is the full http path to the resource on the LAN.
>>>
>>
>> Are you certain that value is what the method sees?
>>
>>> Anything obvious wrong? It's a path to a .png
>>> [I can access the LAN OK, and Data.defaultCoverArt works fine]
>>>
>>> public static void updateCoverArt(String coverArtURLStr)
>>> {
>>> String coverArtURL = coverArtURLStr;
>>>
>>
>> Why the extra 'String' assignment?
>>
>> What is the *actual* value of 'coverArtURLStr' at this point when you
>> have the problem?
>>
>>> Drawable d;
>>>
>>> if (coverArtURL.equals(""))
>>> d = Data.defaultCoverArt;
>>> else
>>> d = Drawable.createFromPath(coverArtURL);
>>>
>>
>> The value of 'd' at this point when you have the problem is 'null',
>> you say.
>>
>>> Data.coverArtIV.setImageDrawable(d);
>>> }
>>>
>>
>> When you say "I can access the LAN OK", that may or may not bear on
>> whether your program can access the LAN when you're running your
>> test. There's insufficient information in your post for us to know.
>>
>> Since you have not provided an SSCCE there's little likelihood we can
>> debug your problem. On the face of it the'createFromPath()' method is
>> unable to access the actual URL string you're giving it, a datum you
>> have omitted from your problem statement.
>>
>> Provide an SSCCE, please.

> Actually, there is enough information.

Now that you've shared it, sure, but not before in the post in which I pointed 
out you didn't provide enough information.

> It seems that
> Drawable.createFromPath(coverArtURL);
>
> doesn't like it if the path is http:\\...

That information was *not* in your post, so no, there was *not* enough 
information in your post.  I am happy that we found the correct answer despite 
that.  It is strange that you're claiming to have provided enough information 
by citing data that you did not provide us.

Yes, of course it can't parse a URL string of that form.  Had you included 
that datum in the original post we could have answered with complete certainty 
instead of probabilistically (and, as it turned out, correctly).  We'd have 
seen that you used backslashes in the URL string, and been able to focus right 
in on that for you.

At least we were able to focus on the string itself and the likelihood (now 
certainty) that it specified an unreachable (or outright invalid) location, 
based on the information that was available.

> I've just got it to work.
> I'll post the code tomorrow for reference

Thanks.  That's a good thing.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3066

On 14/04/2011 23:32, Lew wrote:
> On 04/14/2011 04:32 PM, Dirk Bruere at NeoPax wrote:
>> On 14/04/2011 20:06, Lew wrote:
>>> On Apr 14, 1:37 pm, Dirk Bruere at NeoPax<dirk.bru...@gmail.com>
>>> wrote:
>>>> For some reason d=null when creating a drawable from coverArtURLStr,
>>>> which is the full http path to the resource on the LAN.
>>>>
>>>
>>> Are you certain that value is what the method sees?
>>>
>>>> Anything obvious wrong? It's a path to a .png
>>>> [I can access the LAN OK, and Data.defaultCoverArt works fine]
>>>>
>>>> public static void updateCoverArt(String coverArtURLStr)
>>>> {
>>>> String coverArtURL = coverArtURLStr;
>>>>
>>>
>>> Why the extra 'String' assignment?
>>>
>>> What is the *actual* value of 'coverArtURLStr' at this point when you
>>> have the problem?
>>>
>>>> Drawable d;
>>>>
>>>> if (coverArtURL.equals(""))
>>>> d = Data.defaultCoverArt;
>>>> else
>>>> d = Drawable.createFromPath(coverArtURL);
>>>>
>>>
>>> The value of 'd' at this point when you have the problem is 'null',
>>> you say.
>>>
>>>> Data.coverArtIV.setImageDrawable(d);
>>>> }
>>>>
>>>
>>> When you say "I can access the LAN OK", that may or may not bear on
>>> whether your program can access the LAN when you're running your
>>> test. There's insufficient information in your post for us to know.
>>>
>>> Since you have not provided an SSCCE there's little likelihood we can
>>> debug your problem. On the face of it the'createFromPath()' method is
>>> unable to access the actual URL string you're giving it, a datum you
>>> have omitted from your problem statement.
>>>
>>> Provide an SSCCE, please.
>
>> Actually, there is enough information.
>
> Now that you've shared it, sure, but not before in the post in which I
> pointed out you didn't provide enough information.
>
>> It seems that
>> Drawable.createFromPath(coverArtURL);
>>
>> doesn't like it if the path is http:\\...
>
> That information was *not* in your post, so no, there was *not* enough
> information in your post. I am happy that we found the correct answer
> despite that. It is strange that you're claiming to have provided enough
> information by citing data that you did not provide us.

Because at the time I did not know it was relevent

> Yes, of course it can't parse a URL string of that form. Had you

"Of course"? Why is it so obvious?

> included that datum in the original post we could have answered with
> complete certainty instead of probabilistically (and, as it turned out,
> correctly). We'd have seen that you used backslashes in the URL string,
> and been able to focus right in on that for you.

I do not think that's the problem

> At least we were able to focus on the string itself and the likelihood
> (now certainty) that it specified an unreachable (or outright invalid)
> location, based on the information that was available.
>
>> I've just got it to work.
>> I'll post the code tomorrow for reference
>
> Thanks. That's a good thing.
>

  public static void updateCoverArt(String coverArtURLStr)
     {
     	
     	int height=Constants.ART_HEIGHT, width=Constants.ART_WIDTH;
     	Drawable d;
     	ImageView iv = Data.coverArtIV;
         URL url = null;

         if (coverArtURLStr.equals(""))
         {
         	d = Data.defaultCoverArt;
         }
         else
         {
         	try
         	{
         		url = new URL(coverArtURLStr);
         	} catch (MalformedURLException e) {e.printStackTrace();}
		
         	InputStream content = null;
         	try
         	{
         		content = (InputStream)url.getContent();
         	} catch (IOException e) {e.printStackTrace();}
		
         	d = Drawable.createFromStream(content , "src");
         }
         iv.setImageDrawable(d);
         iv.setAdjustViewBounds(true);
         iv.setMaxHeight(height);
         iv.setMinimumHeight(height);
         iv.setMaxWidth(width);
         iv.setMinimumWidth(width);

     }
-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [prev] | [next] | [standalone]

#3067

On 4/14/2011 4:52 PM, Dirk Bruere at NeoPax wrote:
> On 14/04/2011 23:32, Lew wrote:
...
>> That information was *not* in your post, so no, there was *not* enough
>> information in your post. I am happy that we found the correct answer
>> despite that. It is strange that you're claiming to have provided enough
>> information by citing data that you did not provide us.
>
> Because at the time I did not know it was relevent

That is the perfect summary of the argument in favor of constructing and
posting an SSCCE.

An SSCCE includes all actually relevant information, regardless of
whether the person constructing the SSCCE is aware of its relevance.

Constructing a non-SSCCE excerpt the contains all information that is
actually relevant is much harder. It requires the programmer to know
what is relevant to the problem without knowing enough to solve it, a
rare condition.

Patricia

[toc] | [prev] | [next] | [standalone]

#3068

On 15/04/2011 01:28, Patricia Shanahan wrote:
> On 4/14/2011 4:52 PM, Dirk Bruere at NeoPax wrote:
>> On 14/04/2011 23:32, Lew wrote:
> ...
>>> That information was *not* in your post, so no, there was *not* enough
>>> information in your post. I am happy that we found the correct answer
>>> despite that. It is strange that you're claiming to have provided enough
>>> information by citing data that you did not provide us.
>>
>> Because at the time I did not know it was relevent
>
> That is the perfect summary of the argument in favor of constructing and
> posting an SSCCE.
>
> An SSCCE includes all actually relevant information, regardless of
> whether the person constructing the SSCCE is aware of its relevance.
>
> Constructing a non-SSCCE excerpt the contains all information that is
> actually relevant is much harder. It requires the programmer to know
> what is relevant to the problem without knowing enough to solve it, a
> rare condition.
>
> Patricia

Well, I have just got another problem that cannot be done this way, 
unless I post the whole program.

I have multiple listviews each containing hundreds of strings.
I switch between them with various buttons.
When they load, they are fine.
However, if I use a finger to scroll the screen up and then switch to 
another listview while the last one is still scrolling I get entries 
broken into multiple lines that persist.

My bug, Android 2.2 bug or h/w problem?

-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [prev] | [next] | [standalone]

#3072

On 4/14/2011 6:20 PM, Dirk Bruere at NeoPax wrote:
> On 15/04/2011 01:28, Patricia Shanahan wrote:
>> On 4/14/2011 4:52 PM, Dirk Bruere at NeoPax wrote:
>>> On 14/04/2011 23:32, Lew wrote:
>> ...
>>>> That information was *not* in your post, so no, there was *not* enough
>>>> information in your post. I am happy that we found the correct answer
>>>> despite that. It is strange that you're claiming to have provided
>>>> enough
>>>> information by citing data that you did not provide us.
>>>
>>> Because at the time I did not know it was relevent
>>
>> That is the perfect summary of the argument in favor of constructing and
>> posting an SSCCE.
>>
>> An SSCCE includes all actually relevant information, regardless of
>> whether the person constructing the SSCCE is aware of its relevance.
>>
>> Constructing a non-SSCCE excerpt the contains all information that is
>> actually relevant is much harder. It requires the programmer to know
>> what is relevant to the problem without knowing enough to solve it, a
>> rare condition.
>>
>> Patricia
>
> Well, I have just got another problem that cannot be done this way,
> unless I post the whole program.
>
> I have multiple listviews each containing hundreds of strings.
> I switch between them with various buttons.
> When they load, they are fine.
> However, if I use a finger to scroll the screen up and then switch to
> another listview while the last one is still scrolling I get entries
> broken into multiple lines that persist.

It sure sounds like SSCCE material to me. I would start with questions
like how many listviews are needed, and how many strings per view.

>
> My bug, Android 2.2 bug or h/w problem?
>

If this happened in non-Android Java, I would suggest checking that all
GUI activity is on the event dispatching thread. It sounds as though the
view change is being processed before the scroll has finished, which
should be prevented by doing both in the same thread.

Maybe you should do the equivalent check?

Patricia

[toc] | [prev] | [next] | [standalone]

#3075

On 15/04/2011 05:20, Patricia Shanahan wrote:
> On 4/14/2011 6:20 PM, Dirk Bruere at NeoPax wrote:
>> On 15/04/2011 01:28, Patricia Shanahan wrote:
>>> On 4/14/2011 4:52 PM, Dirk Bruere at NeoPax wrote:
>>>> On 14/04/2011 23:32, Lew wrote:
>>> ...
>>>>> That information was *not* in your post, so no, there was *not* enough
>>>>> information in your post. I am happy that we found the correct answer
>>>>> despite that. It is strange that you're claiming to have provided
>>>>> enough
>>>>> information by citing data that you did not provide us.
>>>>
>>>> Because at the time I did not know it was relevent
>>>
>>> That is the perfect summary of the argument in favor of constructing and
>>> posting an SSCCE.
>>>
>>> An SSCCE includes all actually relevant information, regardless of
>>> whether the person constructing the SSCCE is aware of its relevance.
>>>
>>> Constructing a non-SSCCE excerpt the contains all information that is
>>> actually relevant is much harder. It requires the programmer to know
>>> what is relevant to the problem without knowing enough to solve it, a
>>> rare condition.
>>>
>>> Patricia
>>
>> Well, I have just got another problem that cannot be done this way,
>> unless I post the whole program.
>>
>> I have multiple listviews each containing hundreds of strings.
>> I switch between them with various buttons.
>> When they load, they are fine.
>> However, if I use a finger to scroll the screen up and then switch to
>> another listview while the last one is still scrolling I get entries
>> broken into multiple lines that persist.
>
> It sure sounds like SSCCE material to me. I would start with questions
> like how many listviews are needed, and how many strings per view.

4 listviews, with between 100 and 2000 strings in each

>> My bug, Android 2.2 bug or h/w problem?
>>
>
> If this happened in non-Android Java, I would suggest checking that all
> GUI activity is on the event dispatching thread. It sounds as though the
> view change is being processed before the scroll has finished, which
> should be prevented by doing both in the same thread.
>
> Maybe you should do the equivalent check?

Yes.
Anyway, its not a major bug - there are other things to do first

-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [prev] | [next] | [standalone]

#3078

On 4/15/2011 3:38 AM, Dirk Bruere at NeoPax wrote:
> On 15/04/2011 05:20, Patricia Shanahan wrote:
>> On 4/14/2011 6:20 PM, Dirk Bruere at NeoPax wrote:
>>> On 15/04/2011 01:28, Patricia Shanahan wrote:
>>>> On 4/14/2011 4:52 PM, Dirk Bruere at NeoPax wrote:
>>>>> On 14/04/2011 23:32, Lew wrote:
>>>> ...
>>>>>> That information was *not* in your post, so no, there was *not*
>>>>>> enough
>>>>>> information in your post. I am happy that we found the correct answer
>>>>>> despite that. It is strange that you're claiming to have provided
>>>>>> enough
>>>>>> information by citing data that you did not provide us.
>>>>>
>>>>> Because at the time I did not know it was relevent
>>>>
>>>> That is the perfect summary of the argument in favor of constructing
>>>> and
>>>> posting an SSCCE.
>>>>
>>>> An SSCCE includes all actually relevant information, regardless of
>>>> whether the person constructing the SSCCE is aware of its relevance.
>>>>
>>>> Constructing a non-SSCCE excerpt the contains all information that is
>>>> actually relevant is much harder. It requires the programmer to know
>>>> what is relevant to the problem without knowing enough to solve it, a
>>>> rare condition.
>>>>
>>>> Patricia
>>>
>>> Well, I have just got another problem that cannot be done this way,
>>> unless I post the whole program.
>>>
>>> I have multiple listviews each containing hundreds of strings.
>>> I switch between them with various buttons.
>>> When they load, they are fine.
>>> However, if I use a finger to scroll the screen up and then switch to
>>> another listview while the last one is still scrolling I get entries
>>> broken into multiple lines that persist.
>>
>> It sure sounds like SSCCE material to me. I would start with questions
>> like how many listviews are needed, and how many strings per view.
>
> 4 listviews, with between 100 and 2000 strings in each
>
>>> My bug, Android 2.2 bug or h/w problem?
>>>
>>
>> If this happened in non-Android Java, I would suggest checking that all
>> GUI activity is on the event dispatching thread. It sounds as though the
>> view change is being processed before the scroll has finished, which
>> should be prevented by doing both in the same thread.
>>
>> Maybe you should do the equivalent check?
>
> Yes.
> Anyway, its not a major bug - there are other things to do first
>

Incidentally, this is a case where the building-up approach to an SSCCE
might be helpful. If you wrote an SSCCE from scratch, it could have the
right number of listviews and strings, but would probably not share any
program bugs. You could use a string generator to get the thousands of
strings in a short program.

If it runs correctly, the problem is more likely to be in your program.
If it reproduces the failure, it is more likely to be hardware or system
software.

Patricia

[toc] | [prev] | [next] | [standalone]

#3500

Any suggestions as to why this url causes an exception (I assume its 
illegal characters or something)

http://192.168.0.6:8081/video/clip_art/pan's.labyrinth[2006]dvdrip[eng.sub]-axxo+new.+swesub.+prien.avi.jpg

and this does not
http://192.168.0.6:8081/Audio/Album+Art/P-T/Therion_Sirius+B.jpg

when used here:

InputStream content = (InputStream) url.getContent();

-- 
Dirk

http://www.neopax.com/technomage/ - My new book - Magick and Technology

[toc] | [prev] | [next] | [standalone]

#3501

On 5/4/2011 10:29 AM, Dirk Bruere at NeoPax wrote:
> Any suggestions as to why this url causes an exception (I assume its
> illegal characters or something)
>
> http://192.168.0.6:8081
          ^^^^^^^^^^^

These are local addresses.  No, I have no idea why your internal, local 
IP address is returning an error.

[toc] | [prev] | [next] | [standalone]

#3502

On 04/05/2011 19:29, Dirk Bruere at NeoPax allegedly wrote:
> Any suggestions as to why this url causes an exception (I assume its
> illegal characters or something)
>
> http://192.168.0.6:8081/video/clip_art/pan's.labyrinth[2006]dvdrip[eng.sub]-axxo+new.+swesub.+prien.avi.jpg
>
>
> and this does not
> http://192.168.0.6:8081/Audio/Album+Art/P-T/Therion_Sirius+B.jpg
>
> when used here:
>
> InputStream content = (InputStream) url.getContent();

java.net.URLEncoder

[toc] | [prev] | [next] | [standalone]

#3547

On 04/05/11 18:29, Dirk Bruere at NeoPax wrote:
> Any suggestions as to why this url causes an exception (I assume its
> illegal characters or something)
> 
> http://192.168.0.6:8081/video/clip_art/pan's.labyrinth[2006]dvdrip[eng.sub]-axxo+new.+swesub.+prien.avi.jpg
> 
> 
> and this does not
> http://192.168.0.6:8081/Audio/Album+Art/P-T/Therion_Sirius+B.jpg
> 
> when used here:
> 
> InputStream content = (InputStream) url.getContent();
> 

It should be encoded with java.net.URLEncoder. There are characters in
that string which are not "safe" within a URL.


From RFC 1738:
> Unsafe:
> 
>    Characters can be unsafe for a number of reasons.  The space
>    character is unsafe because significant spaces may disappear and
>    insignificant spaces may be introduced when URLs are transcribed or
>    typeset or subjected to the treatment of word-processing programs.
>    The characters "<" and ">" are unsafe because they are used as the
>    delimiters around URLs in free text; the quote mark (""") is used to
>    delimit URLs in some systems.  The character "#" is unsafe and should
>    always be encoded because it is used in World Wide Web and in other
>    systems to delimit a URL from a fragment/anchor identifier that might
>    follow it.  The character "%" is unsafe because it is used for
>    encodings of other characters.  Other characters are unsafe because
>    gateways and other transport agents are known to sometimes modify
>    such characters. These characters are "{", "}", "|", "\", "^", "~",
>    "[", "]", and "`".
> 
>    All unsafe characters must always be encoded within a URL. For
>    example, the character "#" must be encoded within URLs even in
>    systems that do not normally deal with fragment or anchor
>    identifiers, so that if the URL is copied into another system that
>    does use them, it will not be necessary to change the URL encoding.
> 
> 

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#3077

Dirk Bruere at NeoPax wrote:
> Lew wrote:
>> Dirk Bruere at NeoPax wrote:
[snip]
>>> It seems that
>>> Drawable.createFromPath(coverArtURL);
>>>
>>> doesn't like it if the path is http:\\...

>> That information was *not* in your post, so no, there was *not* enough
>> information in your post. I am happy that we found the correct answer
>> despite that. It is strange that you're claiming to have provided enough
>> information by citing data that you did not provide us.

> Because at the time I did not know it was relevent

Hence the need for an SSCCE.

You knew it was there.  You knew you didn't provide it.  You *assumed* it 
wasn't relevant.  Here's the guideline:  *all* the information is relevant.

This still doesn't explain how you claim there's "enough information" when you 
omitted to provide that information to us.  It's not "enough" if you don't 
share it.

>> Yes, of course it can't parse a URL string of that form. Had you
>
> "Of course"? Why is it so obvious?

Backslashes, duhh.

>> included that datum in the original post we could have answered with
>> complete certainty instead of probabilistically (and, as it turned out,
>> correctly). We'd have seen that you used backslashes in the URL string,
>> and been able to focus right in on that for you.

> I do not think that's the problem

You *told* us that's the problem!  See the first line in this post that I 
quoted from you: "doesn't like it if the path is http:\\...".  That was you 
who posted that, right?

Why do you suddenly think that's not the problem, after telling us that it is?

Where's our SSCCE demonstrating the problem, if that isn't it?

Why when everyone says "SSCCE" do you argue against it, yet still demand that 
we service you, oh, master?  Don't you think you're being insufferably rude, 
arrogant presumptuous by obstinately refusing to cooperate, yet still 
demanding of us to be your little help slaves?

Because you are.

Stop giving out tiny, incomplete little dribs and drabs of useless data, 
contradicting yourself, and refusing to provide what we simply need to help 
&you*, or at least stop expecting people to volunteer to answer your questions 
if you flat-out refuse ask them cooperatively or intelligently.

Please.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web