[android-developers] Re: abstract Uri?

2012-10-05 Thread Lew 
Indicator Veritatis wrote:

 You question the 'naturalness' of his desire to use 'new', but you don't 
 seem to notice: you have merely moved the question, not answered it. Of 
 course it 


Actually, I did answer it.
 

 is 'unnatural' to call 'new' on an abstract class, but he was asking why 
 it was made abstract in the first place. You did not address this. Nor does 
 the Google documentation of the class.


Actually, I did address it.
 


 All you did was move the question to why is calling a factory method more 
 'natural'? After all, factory methods are for when you do NOT know ahead 
 of 


That is only part of what I did.
 

 time exactly which class the created method will be. But why would that be 
 the case here? THAT is what needs to be explained.


I explained that it might be necessary, and that that is the usual reason 
for abstract classes with factory methods in Java.

I speculated as to what factors would make such a decision attractive to 
the API designer.
 


 Nor is it clear why you think there should be no obvious implementors of a 
 class named 'Uri'. One obvious implementation of a class with such a name 


I didn't say I think there should be no obvious implementors of a class 
named 'Uri'. 
I don't actually think that.
That could explain why it's not obvious why I think that.
 

 would be 1) Constructor takes string, returns (opaque?) integer handle for 
 uri 2) methods for opening, closing, fetching resource at uri given by 
 handle. But this is not the way Google did it; the Uri class instead has a 
 noticeably more restricted scope. It does not provide methods for opening a 
 Uri and fetching resources. Instead, the main methods provided are for 
 analyzing the Uri string itself, breaking it down into port, authority (if 
 any), query string etc. Other objects are then responsible for fetching.


That's nice.
 


 What benefit they got from doing it this way is far from clear, especially 
 since they are now recommending use of java.net for external HTTP access 
 for recent versions of Java, using android.net mainly for the internal 
 Uris used for Content Providers.


Well, we can but speculate, as I did.  


 As for using the Wikipedia entry, I have been often disappointed by 
 Wikipedia entries on OOD topics before. This time also, since they put the 
 reader through an alleged Java example of the Factory method (complex 
 numbers), and then admit that strictly speaking, it is not even an example 
 of the pattern. This is NO help to the learner, and little help to the 
 seasoned programmer.


I found it helpful, both as a learner and as a seasoned programmer. I'm 
sorry you found it less useful. 


 Finally, it is ironic that you observe (correct though that is), that use 
 of factory methods is prevalent throughout the Java API. For java.net.URI 
 is NOT abstract, but android.net.Uri IS abstract. The similarity of these 
 names is probably a large part of why the OP expected both to be concrete. 
 Both claim, after all, to do roughly the same thing: represent a URI (one 
 immutable, the other mutable). The differences in the API alone do not 
 really explain why they made it abstract.


Nor do my speculations. They only provide pointers to the type of reasoning 
involved in creating factory methods.

I guess you're angry that I didn't break out my crystal ball and read the 
Android team's mind. I do apologize for that.

-- 
Lew
 


 bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?


 You got the what, now for the why.
  

 Naturally, I want to do something like this:

 I question the naturalness of that desire.
  

 Uri uri = new Uri(http://www.example.com/file.mp4;);


 It's more natural, some would say, to use a factory method. (Google Java 
 factory method 
 and you'll find, e.g., 
 http://en.wikipedia.org/wiki/Factory_method_pattern#Java, complete 
 with reference to Josh Bloch's advice on the matter.)

 It's entirely unnatural to want to call a constructor on an abstract 
 class. Such a class with 
 no obvious implementors is a signal that it has a factory method. This is 
 quite prevalent 
 in the Java API.

 The why is to save the client from messy and irrelevant details of the 
 implementation.
 You shouldn't have to decide which particular flavor of 'Uri' to 
 instantiate, especially if the 
 thing is tricky (e.g., has to support an ever-expanding list of 
 protocols). Let the factory 
 manufacture you one and you save all that headache.

 Study up on the reasons to prefer a factory method, and when not to.

 -- 
 Lew


  



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: abstract Uri?

2012-10-04 Thread RichardC 
Did you look at Uri.Builder?
http://developer.android.com/reference/android/net/Uri.Builder.html

On Thursday, October 4, 2012 6:59:02 PM UTC+1, bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?

 Naturally, I want to do something like this:

 Uri uri = new Uri(http://www.example.com/file.mp4;);



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: abstract Uri?

2012-10-04 Thread RichardC 
and also this method:
http://developer.android.com/reference/android/net/Uri.html#parse(java.lang.String)

On Thursday, October 4, 2012 6:59:02 PM UTC+1, bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?

 Naturally, I want to do something like this:

 Uri uri = new Uri(http://www.example.com/file.mp4;);



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: abstract Uri?

2012-10-04 Thread Lew 
bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?


You got the what, now for the why.
 

 Naturally, I want to do something like this:

 I question the naturalness of that desire.
 

 Uri uri = new Uri(http://www.example.com/file.mp4;);


It's more natural, some would say, to use a factory method. (Google Java 
factory method 
and you'll find, e.g., 
http://en.wikipedia.org/wiki/Factory_method_pattern#Java, complete 
with reference to Josh Bloch's advice on the matter.)

It's entirely unnatural to want to call a constructor on an abstract class. 
Such a class with 
no obvious implementors is a signal that it has a factory method. This is 
quite prevalent 
in the Java API.

The why is to save the client from messy and irrelevant details of the 
implementation.
You shouldn't have to decide which particular flavor of 'Uri' to 
instantiate, especially if the 
thing is tricky (e.g., has to support an ever-expanding list of protocols). 
Let the factory 
manufacture you one and you save all that headache.

Study up on the reasons to prefer a factory method, and when not to.

-- 
Lew


 

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: abstract Uri?

2012-10-04 Thread bob 
Looks like the answer can be understood partly by looking at these 
functions:

425 public static Uri parse(String uriString) {
426 return new StringUri(uriString);
427 }







439 public static Uri fromFile(File file) {
440 if (file == null) {
441 throw new NullPointerException(file);
442 }
443 
444 PathPart path = PathPart.fromDecoded(file.getAbsolutePath());
445 return new HierarchicalUri(
446 file, Part.EMPTY, path, Part.NULL, Part.NULL);
447 }





805 public static Uri fromParts(String scheme, String ssp,
806 String fragment) {
807 if (scheme == null) {
808 throw new NullPointerException(scheme);
809 }
810 if (ssp == null) {
811 throw new NullPointerException(ssp);
812 }
813 
814 return new OpaqueUri(scheme, Part.fromDecoded(ssp),
815 Part.fromDecoded(fragment));
816 }



On Thursday, October 4, 2012 3:05:58 PM UTC-5, Lew wrote:

 bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?


 You got the what, now for the why.
  

 Naturally, I want to do something like this:

 I question the naturalness of that desire.
  

 Uri uri = new Uri(http://www.example.com/file.mp4;);


 It's more natural, some would say, to use a factory method. (Google Java 
 factory method 
 and you'll find, e.g., 
 http://en.wikipedia.org/wiki/Factory_method_pattern#Java, complete 
 with reference to Josh Bloch's advice on the matter.)

 It's entirely unnatural to want to call a constructor on an abstract 
 class. Such a class with 
 no obvious implementors is a signal that it has a factory method. This is 
 quite prevalent 
 in the Java API.

 The why is to save the client from messy and irrelevant details of the 
 implementation.
 You shouldn't have to decide which particular flavor of 'Uri' to 
 instantiate, especially if the 
 thing is tricky (e.g., has to support an ever-expanding list of 
 protocols). Let the factory 
 manufacture you one and you save all that headache.

 Study up on the reasons to prefer a factory method, and when not to.

 -- 
 Lew


  


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: abstract Uri?

2012-10-04 Thread Indicator Veritatis 
You question the 'naturalness' of his desire to use 'new', but you don't 
seem to notice: you have merely moved the question, not answered it. Of 
course it is 'unnatural' to call 'new' on an abstract class, but he was 
asking why it was made abstract in the first place. You did not address 
this. Nor does the Google documentation of the class.

All you did was move the question to why is calling a factory method more 
'natural'? After all, factory methods are for when you do NOT know ahead 
of time exactly which class the created method will be. But why would that 
be the case here? THAT is what needs to be explained.

Nor is it clear why you think there should be no obvious implementors of a 
class named 'Uri'. One obvious implementation of a class with such a name 
would be 1) Constructor takes string, returns (opaque?) integer handle for 
uri 2) methods for opening, closing, fetching resource at uri given by 
handle. But this is not the way Google did it; the Uri class instead has a 
noticeably more restricted scope. It does not provide methods for opening a 
Uri and fetching resources. Instead, the main methods provided are for 
analyzing the Uri string itself, breaking it down into port, authority (if 
any), query string etc. Other objects are then responsible for fetching.

What benefit they got from doing it this way is far from clear, especially 
since they are now recommending use of java.net for external HTTP access 
for recent versions of Java, using android.net mainly for the internal Uris 
used for Content Providers.

As for using the Wikipedia entry, I have been often disappointed by 
Wikipedia entries on OOD topics before. This time also, since they put the 
reader through an alleged Java example of the Factory method (complex 
numbers), and then admit that strictly speaking, it is not even an example 
of the pattern. This is NO help to the learner, and little help to the 
seasoned programmer.

Finally, it is ironic that you observe (correct though that is), that use 
of factory methods is prevalent throughout the Java API. For java.net.URI 
is NOT abstract, but android.net.Uri IS abstract. The similarity of these 
names is probably a large part of why the OP expected both to be concrete. 
Both claim, after all, to do roughly the same thing: represent a URI (one 
immutable, the other mutable). The differences in the API alone do not 
really explain why they made it abstract.


bob wrote:

 Can someone help me understand why the android.net.Uri class is abstract?


 You got the what, now for the why.
  

 Naturally, I want to do something like this:

 I question the naturalness of that desire.
  

 Uri uri = new Uri(http://www.example.com/file.mp4;);


 It's more natural, some would say, to use a factory method. (Google Java 
 factory method 
 and you'll find, e.g., 
 http://en.wikipedia.org/wiki/Factory_method_pattern#Java, complete 
 with reference to Josh Bloch's advice on the matter.)

 It's entirely unnatural to want to call a constructor on an abstract 
 class. Such a class with 
 no obvious implementors is a signal that it has a factory method. This is 
 quite prevalent 
 in the Java API.

 The why is to save the client from messy and irrelevant details of the 
 implementation.
 You shouldn't have to decide which particular flavor of 'Uri' to 
 instantiate, especially if the 
 thing is tricky (e.g., has to support an ever-expanding list of 
 protocols). Let the factory 
 manufacture you one and you save all that headache.

 Study up on the reasons to prefer a factory method, and when not to.

 -- 
 Lew


  


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en