Dec 18 | 7:25 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Dec 18 | 7:35 PM |
Ahmad M. | has entered the room |
Mark M. |
hello, Ahmad!
|
Mark M. |
how can I help you today?
|
Ahmad M. |
hello Mr.Mark
|
Ahmad M. |
yes please
|
Ahmad M. |
i did what you tell me about making Repeat as foreignKey for TodoModel , this is the Repeat Entity :
|
Ahmad M. |
View paste
(25 more lines)
|
Ahmad M. |
the Repeat has RepeatType which is enum
|
Dec 18 | 7:40 PM |
Ahmad M. |
View paste
(15 more lines)
|
Ahmad M. |
and the Repeat Time which is semple class
|
Ahmad M. |
View paste
|
Ahmad M. |
represent time
|
Mark M. |
@Embedded public RepeatType repeatType; -- you should not need @Embedded here
|
Mark M. |
RepeatType will go into a single column in your table, by way of your @TypeConverter methods
|
Mark M. |
you should be able to skip the @Embedded annotation
|
Ahmad M. |
yes u right
|
Ahmad M. |
this cope i make to u
|
Ahmad M. |
this is the Weekly Repeat Class
|
Ahmad M. |
View paste
|
Ahmad M. |
and this is the Monthly Repeat Class
|
Ahmad M. |
View paste
(3 more lines)
|
Dec 18 | 7:45 PM |
Aaron | has entered the room |
Mark M. |
(hello, Aaron -- I will be with you after Ahmad has had a chance to ask a question!)
|
Aaron |
thanks
|
Ahmad M. |
and i notes that every field in the Entity should not have the same name as in the "days" field in the Weekly repeat class and Monthly repeat class
|
Ahmad M. |
is this structure for my Database is right?
|
Mark M. |
well, other than the unnecessary @Embedded on the RepeatType field, there is nothing I see that is wrong
|
Dec 18 | 7:50 PM |
Mark M. |
personally, I would try to model it differently, but that is a question of my preferences versus yours
|
Dec 18 | 7:50 PM |
Ahmad M. |
all this because the user going to chose one of the Repeating types
|
Ahmad M. |
maybe Weekly or Monthly ext
|
Ahmad M. |
is there any way better
|
Mark M. |
I do not know what "better" would be for you
|
Ahmad M. |
if the user chose weekly Type the other Types well all be null
|
Ahmad M. |
can i chose the one Entity from many at run Time
|
Mark M. |
one approach for that is inheritance, where you would have a RepeatBase class that has the common things, and subclasses for different varieties (weekly, monthly, yearly)
|
Mark M. |
it makes the relations more complex, but it keeps the individual classes simpler
|
Mark M. |
see the "Polymorphic Room Relations" chapter in "Android's Architecture Components" for more about that
|
Dec 18 | 7:55 PM |
Mark M. |
another possibility is that you do not try to have individual columns/fields for each discrete piece of data
|
Mark M. |
instead, you use some other encoding system
|
Mark M. |
for example, the iCalendar specification has a whole language for repeat rules (RRULE, if I remember the name correctly)
|
Mark M. |
those just get represented as text that you would parse
|
Mark M. |
so, you could say that your ToDo items have a List<String>, where each String represents a single iCalendar repeat rule
|
Mark M. |
you would have to write the code to parse and generate the rule strings, but it would simplify your database structure a lot
|
Mark M. |
my guess is that you are not going to be querying the database for the individual fields much
|
Mark M. |
for example, you are unlikely to be executing a SQL SELECT statement where you are querying on daysInTheWeek
|
Ahmad M. |
what are u mean about "it makes the relations more complex"
|
Mark M. |
each subclass of RepeatBase gets its own table
|
Mark M. |
as each subclass would be its own @Entity
|
Mark M. |
so ToDo would have relations to three separate entity classes
|
Mark M. |
rather than just the one that you have right now
|
Mark M. |
let me take a question from Aaron, and I will return to you shortly
|
Mark M. |
Aaron: your turn, do you have a question?
|
Ahmad M. |
ok
|
Mark M. |
(and since I know you usually come with a list... could you post just one?)
|
Aaron |
sure
|
Aaron |
um, this is 2 parts so I'll just post the first
|
Aaron |
View paste
|
Dec 18 | 8:00 PM |
Mark M. |
I have no idea how to do what you are seeking, sorry
|
Mark M. |
since that was pretty quick, what's the second part of the question?
|
Aaron |
b) For colorNightBg and colorAmoledNightBg, as per their names, these colors are only used in night mode and I don't want/need to use them in the default colors.xml at all. However the app crashes (and Lint complains, I believe) when they are not also included in the default colors.xml, so I am unnecessarily repeating them there. Is there anything to do about that?
|
Mark M. |
your problem would then lie in where you are using these, presumably
|
Mark M. |
the point behind resource sets is that you should not have dedicated resources along the same axis as the set
|
Mark M. |
so, for example, you would not have app_name and app_name_french as string resources
|
Mark M. |
you would just have app_name, with values in res/values and res/values-en/
|
Mark M. |
so, colorNightBg is a code smell
|
Mark M. |
it should just be colorBg
|
Mark M. |
where you use that color all the time
|
Aaron |
yes, understood, and the only reason I have this is because of the AMOLED night mode, where I have two possible values for the background color when the app is in night mode
|
Dec 18 | 8:05 PM |
Aaron |
after the user puts it into night mode, they can additionally select AMOLED night mode in which case the background is set to pure black, so there is no day mode analogue
|
Mark M. |
I guess I don't understand the significance of AMOLED night mode with respect to what you're doing, but OK
|
Mark M. |
then there's something else afoot
|
Mark M. |
res/values/ is the default; res/values-night/ overrides them
|
Mark M. |
there is never a need to duplicate a value in an override
|
Mark M. |
so your app crash is inexplicable, and I'd need a lot more to go on to help with that (code, stack trace, etc.)
|
Mark M. |
in terms of Lint warnings, that could just be an over-aggressive Lint check
|
Mark M. |
though it's possible that whatever is causing the crash might have a trickle-down effect on Lint
|
Mark M. |
oh, wait
|
Mark M. |
I had your problem inverted
|
Mark M. |
you avoid the duplication by putting the colorNightBg in res/values/ and leave it out of res/values-night/
|
Aaron |
ah, yes
|
Mark M. |
the fact that *you* happen to only be using it in night mode is a red herring from the standpoint of Android's resource system
|
Mark M. |
for all Android knows, you only use colorNightBg on the user's birthday
|
Aaron |
OK that's what I was looking for
|
Aaron |
makes sense
|
Mark M. |
sorry it took me so long to wrap my head around that
|
Aaron |
and I see why it is crashing now, too, thanks, please feel free to switch back to Ahmad
|
Aaron |
no worries
|
Dec 18 | 8:10 PM |
Mark M. |
Ahmad: your turn! do you have another question?
|
Ahmad M. |
yes
|
Ahmad M. |
are u mean like this :
|
Ahmad M. |
View paste
(6 more lines)
|
Ahmad M. |
View paste
|
Mark M. |
yes, something like that
|
Mark M. |
WeeklyRepeat is simpler than your original Repeat class and has fewer unnecessary fields
|
Mark M. |
the same will be true for the other subclasses of RepeatBase
|
Ahmad M. |
ok
|
Mark M. |
when you load your ToDo instances, you will need to retrieve the repeat rules from these other entities, rather than just from the one Repeat entity
|
Ahmad M. |
when i query for single Todo i'll query for it in at least 3 Entity right
|
Ahmad M. |
??
|
Mark M. |
well, there is still just one ToDo entity and table
|
Mark M. |
remember that Room does not automatically retrieve related entities when you do a query
|
Dec 18 | 8:15 PM |
Ahmad M. |
uha
|
Mark M. |
View paste
|
Ahmad M. |
that is rghit
|
Mark M. |
you will then need to also have DAO methods for retrieving the weekly, monthly, and yearly repeat rules
|
Mark M. |
in that chapter that I mentioned on polymorphic Room relations, I have some suggestions on how to set up that sort of thing
|
Ahmad M. |
yes that is esey
|
Mark M. |
along with sample code
|
Ahmad M. |
give your suggestions pleas
|
Mark M. |
ummm... suggestions for what?
|
Ahmad M. |
uha i think u have more suggestions for me
|
Ahmad M. |
thank u Mr.Mark
|
Mark M. |
you are welcome!
|
Mark M. |
Aaron: your turn! do you have another question?
|
Aaron |
yes, and this is actually my only other question today
|
Aaron |
Is it accurate to say that in plain Java a Future is analogous to an Rx Disposable, with the main difference being that Futures also get you the result value, whereas Disposables do not? Also, it seems that Futures play no role in Rx. Is there a reason why Rx didn't include/build on Futures in some way?
|
Mark M. |
I have not used Future in Java
|
Aaron |
ok, no worries
|
Mark M. |
so I can't really comment on it -- sorry
|
Mark M. |
for whatever reason, it hasn't seemed that popular in Android circles, even though we've had it since the beginning
|
Dec 18 | 8:20 PM |
Aaron |
as a final comment, I think it is wild that there is no stylesheet-inspector-like tool for layouts, with regard to my first question
|
Aaron |
this problem keeps coming up for me, but I can barely find anyone talking about it online
|
Mark M. |
well, that's not that easy to create
|
Aaron |
yes, true, I am just surprised that more people aren't asking for it
|
Mark M. |
for example, you mentioned that the Layout Inspector doesn't show you where the value came from
|
Mark M. |
that's because all the Layout Inspector knows is what the final value is
|
Mark M. |
the Layout Inspector doesn't even really know the state of the Configuration, let alone have all of the details of how the resource sets got applied
|
Mark M. |
that would take something a bit more like the layout editor, which basically starts with your code and generates a preview
|
Ahmad M. | has left the room |
Mark M. |
it also really runs the code for the widgets, which is why the preview looks as accurate as it does
|
Aaron |
yes, that makes sense why it has not been developed, I just would have expected more complaining
|
Aaron |
I've found like one stackoverflow post asking for such a thing
|
Mark M. |
oh, there are probably people complaining
|
Aaron |
/shrug
|
Mark M. |
it's just that we have a *lot* of complaints
|
Aaron |
not as many as I would have expected
|
Aaron |
ha
|
Aaron |
OK, well thanks for the info
|
Mark M. |
that one probably doesn't rise above the level of complaint background noise
|
Aaron |
I will suffer in silence
|
Aaron |
have a nice night!
|
Mark M. |
you too!
|
Aaron | has left the room |
Dec 18 | 8:30 PM |
Mark M. | turned off guest access |